4 


MICROCOPY  RESOLUTION  TEST  CHAjRT 

NATIONAL  BUREAU  OF  STANDARDS  1963-4 


■ ■ ,*. 


STUDY  S-445 


TELEPROCESSING  ISSUES  IN  THE 
DEPARTMENT  OF  DEFENSE 


Joseph  M.  Aein 
Thomas  C.  Bartee 
Ronald  A.  Finkler 


June  1975 


INSTITUTE  FOR  DEFENSE  ANALYSES 
SCIENCE  AND  TECHNOLOGY  DIVISION 


DISTRIBUTION  8TA“ 


HQ74-16813 
of  30  copies 


mater  ialsul 


rt-tQ^continuing  poj^efcTiscussion;  November 
requesTT  f m—jbt^ocoment  most  be  referred 
rect«'  O^HSroceisTnB^^AQg^Office  of  the 
comjjurfffcationj  and  '~\ — -iiTnrrTmd  fYiiilinl 


Published  May  1976 


Approved  for  public  release 
distribution  unlimited 


STUDY  S-445 


TELEPROCESSING  ISSUES  IN  THE 
DEPARTMENT  OF  DEFENSE 


Joseph  M.  Aein 
Thomas  C.  Bartee 
Ronald  A.  Finkler 


June  1975 


INSTITUTE  FOR  DEFENSE  ANALYSES 
SCIENCE  AND  TECHNOLOGY  DIVISION 
400  Army-Navy  Drive,  Arlington,  Virginia  22202 


Contract  DAHC15  73  C 0200 
Teleprocessing 


CONTENTS 


STUDY  SUMMARY  1 

A.  Teleprocessing:  A General  Overview  3 

B.  DoD  Teleprocessing  Applications  7 

C.  Issue:  Dedicated  Versus  Common-User  9 

Teleprocessing  Networks 

D.  Issue:  Current  Teleprocessing  Developmental  15 

Programs 

E.  Issue:  Teleprocessing  Network  Standards  16 

F.  Issue:  Multilevel  Security  17 

G.  Issue:  Network  Switching  19 

H.  Issue:  Teleprocessing  Network  Requirements  21 

and  Analysis 

INTRODUCTION  25 

A.  Background  and  Purpose  25 

B.  Approach  28 

TELEPROCESSING  APPLICATIONS  31 

A.  Application  Types  31 

B.  Type  I Needs  34 

1.  Type  la  Systems --Command  and  Control  35 

Nuclear  Forces 

2.  Type  lb  Systems --Crisis  and  Contingency  39 

Command  and  Control 

C.  Type  II  General  Applications  46 

1 . Introduction  46 

2.  Discussion  of  Type  II  Applications  47 

3.  Merger  of  Existing  Systems:  A Case  Study  50 

4.  Replacement  with  a New  System:  The  Air  52 

Force  SADPR-85  Base  Level  Computer 

Network  Concept 

5.  Proposed  AUTODIN  II  Network  68 

6.  Type  II  Sizing  and  Cost  Model  79 

D.  Summary  86 

REQUIREMENTS  AND  ASSETS  91 

A.  Requirements  91 

1.  Acquisition  Procedure  for  ADP  Hardware  91 

2.  Discussion  93 

B.  ADP  Asset  Inventories  94 

1.  Computer  Asset  Lists  94 

2.  Functional  System  Inventories  101 

3.  Communications  103 

C.  Teleprocessing  Systems  103 

D.  Summary  107 


iii 


V.  DESIGN  AND  ARCHITECTURAL  CONSIDERATIONS  109 

A.  Design  Topology  and  Analysis  110 

1.  Topological  Types  110 

2.  Design  and  Analysis  116 

B.  System  Sharing  121 

1.  Sharing  Elements  121 

2.  Sharing  and  Switching  122 

C.  Network  Design  Problems  126 

1.  Overview  and  ARPANET  127 

2.  Flow  Control  127 

3.  Reliability/Survivability  129 

4.  Packet/Circuit  Switching  Comparisons  130 

5.  Access  Performance  132 

6.  Buffer  Analysis  132 

7.  Architecture  and  Performance  Modeling  133 

D.  Summary  134 

VI.  COMPUTER  AND  DATA  COMMUNICATIONS  FUTURE  137 

ENVIRONMENT 

A.  Communications  138 

1.  Introduction  138 

2.  Current  Environment  138 

3.  Future  Environment  146 

B.  Summary  154 

VII.  SELECTED  SYSTEM  RED  ISSUES  AND  NEEDS  159 

A.  Requirements,  Activity  Modeling,  and  System  159 
Evaluation 

B.  Data  Interface  Standards  161 

1.  Introduction  161 

2.  Current  Context  162 

3.  ADCCP  Example  164 

4.  Network/Subscriber  Interface  166 

C.  Data  Switching  Techniques  169 

1.  Background  169 

2.  Packet  Switching  171 

3.  Circuit  Switching  176 

4.  Summary  177 

D.  Network  Control  179 

E.  Multilevel  Security  for  Data  Transmission  181 

F.  Network  Interconnection  183 

G.  Computer  Science  184 

H.  Summary  185 


iv 


VIII.  DOD  DEVELOPMENTAL  SYSTEMS  AND  STANDARDS  189 

A.  System  Standards  190 

B.  Teleprocessing  Systems  Capabilities  191 

1.  Terminal  Servicing- -Interactive  Systems  191 

2.  Data  Base  File  Transfers  192 

3.  Remote  Job  Entry  193 

4.  Teleconferencing  193 

C.  Teleprocessing  Systems  Protocols  193 

D.  FWIN--The  DoD  Experimental  Teleprocessing  196 

System 

E.  The  ANMCC-NMCSSC  Intercomputer  Link  198 

F.  The  AABNCP-SATIN  IV/ANMCC  Intercomputer  Link  201 

G.  Development  of  Standard  Software  Packages  205 

1.  Data  Base  Management  Systems  206 

2.  Standard  Applications  Programs  208 

H.  Summary  210 


APPENDIX  A— Task  Order 


APPENDIX  B — Automatic  Data  Processing  Equipment 
Technology  Forecast 


RE:  Classified  references,  dlstrlbut 
Ian  uni  Ini ted- 

Na  chany a par  Mrs.  Batty  Prlnyle, 

IDA 


1 ACCESSION  for  L 

NTIS 

White  Section  f/ 

ooc 

Buff  Section  □ 

UNANNOUNCED 

O 

JUSTIFICATION  . 

BY 

DISTKmT'T 

’WUSWIY  CC5!S  1 

Oisl 

j.Ai 

SPiUAl 

a 

n 


ABBREVIATIONS 


AABNCP 

Advanced  Airborne  Command  Post 

+ 

ADCCP 

Advanced  Data  Communication  Control  Procedure 

ADL 

Arthur  D.  Little,  Inc. 

p 

ADP 

automatic  data  processing;  automated  data  processing 

V 

ADPE 

automatic  data  processing  equipment 

AFRES 

Air  Force  Reserve 

AFSATCOM 

Air  Force  satellite  communications 

A 

AFSCS 

Air  Force  Satellite  Communications  System 

ANCC 

Army  Northeast  Computer  Center 

ANG 

Air  National  Guard 

ANMCC 

Alternate  National  Military  Command  Center 

ANSI 

American  National  Standards  Institute 

AREUR 

U.S.  Army,  Europe 

ARPA 

Defense  Advanced  Research  Projects  Agency 

i 

ARPAC 

Army  Pacific  Command 

± 

ARPANET 

ARPA  Network 

* 

ARS 

Advanced  Record  System 

♦ 

ASC 

Automatic  Switching  Center 

* 

AT&T 

American  Telephone  and  Telegraph  Corporation 

1 

ATP 

Automated  Telecommunications  Program 

ATS 

Automated  Telecommunications  System 

♦ 

i 

AUTODIN 

Automatic  Digital  Information  Network 

♦ 

♦ 

AUTOVON 

Automatic  Voice  Network 

«» 

BCP 

Base  Communications  Processor 

4» 

BLIS 

Base  Level  Inquiry  System 

BTL 

Bell  Telephone  Laboratories 

i* 


I 


CINC 


CINCEUR 


CINCLANT 


CINCPAC 


CINCSAC 


ComSec 


CONUS 


DTACCS 


EMATS 


I 


command,  control,  and  communications 

Communications  Access  Processor 

Configuration  Analysis  and  Projection  System 

Command- Central  Computer  Network 

Cost-Estimating  Relationships 

Commander  in  Chief 

Commander  in  Chief,  Europe 

Commander  in  Chief,  Atlantic 

Commander  in  Chief,  Pacific 

Commander  in  Chief,  Strategic  Air  Command 

computer  output  microfilm 

Communication  Security 

Continental  United  States 

Communications  Processing  Element 

Central  Processing  Unit 

cathode-ray  tub  5 


Data  Base  Management  System 
Defense  Communications  Agency 
Defense  Communications  System 
Direct  Distance  Dialing 

Digital  Data  System;  Digital  Data  Service;  data 


display  subsystem 
Department  of  Defense 
Data  Project  Plan 

Director,  Telecommunications  and  Command  and 
Control  Systems,  OSD 


data  under  voice 


Emergency  Action  Message 

Emergency  Message  Automatic  Transmission  System 
Electronic  Systems  Division,  AFSC 


Federal  Communications  Commission 


Force  Management  Information  System 


FNP 

o 

FORSTAT 

GEP 

GSA 

V 

GTE 

* 

HCP 

t 

HIS 

i 

IAS 

♦ 

IDN 

IMP 

I/O 

IRS 

JCS 

« fc 

JCSAN 

JOPS 

o 

JTSA 

4 

4 

JUMPS 

♦ 

LSI 

V 

♦ 

MAC 

♦ 

MACIMS 

MBCP 

l 

MEECN 

MIH 

n 

MIS 

• ► 

MTMTS 

fr 

MTS 

Front-end  Network  Processor 

Force  Status  and  Identity  Information  Processing 
System 

Ground  Entry  Point 

General  Services  Administration 

Ground  terminal  equipment 

Headquarters  Communications  Processor 
Honeywell  Information  System 

Immediate  Access  Storage 
Integrated  Data  Network,  DCA 
Interface  Message  Processor 
input/output 

Internal  Revenue  Service 

Joint  Chiefs  of  Staff 

JCS  Alerting  Network 

Joint  Operational  Planning  System 

Joint  Technical  Support  Activity 

Joint  Uniform  Military  Personnel  System 

large-scale  integration 

Military  Airlift  Command 

MAC  Information  Management  System 

Message  Base  Communications  Processor 

Minimum  Essential  Emergency  Communications  Network 

manual  information  handling 

Management  Information  System 

Military  Traffic  Management  and  Terminal  Service 
Manual  Telecommunications  System 


I 


I 


f* 

X. 


ix 


NASA 

NCA 

NDPSC 

NEACP 

NIPS 

NMCC 

NMCS 

NMCSSC 

O&M 

OSD 

OUH 

PACAF 

PACCS 

PACOM 

PCM 

POL 

PWIN 

RCP 

R&D 

REDCOM 

RFP 

RJE 

RJES 

RNP 

RSB 


National  Aeronautics  and  Space  Administration 

National  Command  Authorities 

Navy  Data  Processing  Service  Center 

National  Emergency  Airborne  Command  Post 

National  Information  Processing  System 

National  Military  Command  Center 

National  Military  Command  System 

National  Military  Command  System  Support  Center 

operations  and  maintenance 
Office  of  the  Secretary  of  Defense 
operational  use  hours 

Pacific  Air  Forces 

Post-Attack  Command  and  Control  System,  SAC 

Pacific  Command 

pulse  code  modulation 

petroleum,  oil,  and  lubricants 

Prototype  WWMCCS  Intercomputer  Network 

Regional  Communications  Processor 
research  and  development 
Readiness  Command 
Request  for  Proposal 
remote  job  entry 
Remote  Job  Entry  System 
Remote  Network  Processor 
Remote  Support  Base 


SAC  Strategic  Air  Command 

(SADPR-85  Support  of  Air  Force  Automatic  Data  Processing 


1 

SBS 

Segment  Binary  Synchronous 

V 

SDIU 

Subscriber’s  Digital  Interface  Unit 

SDLC 

Synchronous  Data  Link  Control 

SIOP 

single  integrated  operational  plan 

SLFCS 

Survivable  Low-Frequency  Communication  System,  SAC 

STALOG 

System  to  Automate  Logistics  at  Base  Level 

t 

) 

TDMS 

Time- shared  Data  Management  System 

W 

TIPS 

Terminal  Interface  Processor  System 

TS 

time  sharing 

USAFE 

UTE 

VAN 


U.S.  Air  Forces,  Europe 
user  terminal  equipment 

Value  Added  Network 


1 

I 


I 


1 


WAMTMTS 

WATS 

WIN 

WWDMS 

WWMCCS 


Wide-Area  Military  Traffic  Management  and 
Terminal  Service 

Wide-Area  Telecommunication  Service 
WWMCCS  Internet 

Worldwide  Data  Management  System 

Worldwide  Military  Command  and  Control  System 


xi 


]/  C J c L-P C /?/3,  3 J>A  U idfx  V'  <p/T  ciL 


I.  STUDY  SUMMARY 


In  October  1973,  IDA  was  requested  by  the  Office  of  the 
Assistant  Secretary  of  Defense  (Telecommunications)*  to  undertake  a 
Atask  directed  toward  the  development  of  a basis  for  evaluating  the 
benefits  that  could  result  from  managing  computer  communications  at  a 
teleprocessing  system  level  as  opposed  to  dealing  separately  at  the 
computer  and  communication  levels.  Guidance  was  requested  for  the 
management,  development,  modification,  and  maintenance  of  teleprocess- 
ing systems  to  achieve  potential  improvements . "'Uix  major  areas  that 
influence  teleprocessing  were  identified  for  consideration  (Appendix 
A).  The  intent  in  identifying  these  areas  was  to  give  the  study 
sufficient  latitude  to  explore  and  develop  initial  guidance  in  those 
areas  that  appeared  to  be  most  fruitful  and  significant  in  a limited 
initial  study  phase  consisting  of  28  man-months  of  effort.  It  was 
not  the  intent  of  the  task  to  deal  with  these  six  major  areas  in 
depth,  nor  could  this  study  within  this  limited  level  of  effort 
explore  the  justification  of  implementing  teleprocessing  systems 
within  the  DoD. 

Within  this  limited  scope,  this  study  has  raised  more  questions 
than  it  could  adequately  address.  Little  definitive  experience  with 
teleprocessing  systems  is  available  and  analytic  techniques  are 
rudimentary  with  few  quantitative  data  available  on  which  to  base 
analysis.  As  a result,  most  of  the  study  effort  was  a data-gathering 
task  to  explore  the  current  understandings  of  teleprocessing  systems. 
However,  this  study  has  attempted  to  structure  the  questions  and 
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issues  related  to  DoD  applications  of  teleprocessing  and  to  place 
teleprocessing  in  the  larger  context  of  industry  developments  and 
alternate  approaches  available  for  providing  teleprocessing  systems. 
In  this  context  it  has  had  to  assume  that  the  need  for  teleprocessing 
systems  does  exist  within  the  DoD,  initially  in  command  and  control 
applications,  but  there  have  been  no  assumptions  as  to  the  magnitude 
or  time  frame  of  that  need. 

The  conclusions  of  this  section  are  supported  in  part  by  the 
remainder  of  this  study  and  in  large  part  by  the  results  of  other 
referenced  studies.  Primarily,  these  conclusions  are  based  on  extrap- 
olations from  (1)  the  current  experience  with  the  DoD  developmental 
teleprocessing  systems  (Section  VIII)*;  (2)  the  few  available  studies 
regarding  the  economies  of  scale  of  large  subscriber-oriented  common- 
user  data  transmission  networks  (Section  III);  and  (3)  the  foreseen 
developments  in  the  computer  industry  and  in  the  communication 
services  provided  by  the  Common  and  Special  Carriers  (Section  VI). 
Significant  cost  factors  used  in  the  study  were  obtained  from  other 
referenced  studies  and  no  independent  cost  analyses  or  verification 
of  the  referenced  cost  analyses  were  conducted. 

Teleprocessing  is  defined,  for  the  purposes  of  this  study,  to  be 
the  set  of  functional  capabilities  provided  by  an  integration  of 
communications  and  data  processing  into  a single  cohesive  system. 

The  system  applications  of  teleprocessing  considered  and  identified 
by  the  study  are:  Type  la  (Command  and  Control  <_f  Nuclear  Forces) 
and  Type  lb  (Nonnuclear  Crisis  and  Contingency  Command  and  Control) 


systems  both  of  which  provide  informational  support  to  the  National 
Command  Authorities;  and  Type  II  (General  Data  Processing  Services) 
systems  which  provide  data  processing  and  computational  services  to 
administrative,  support,  and  other  DoD  organizations.  Both  Type  I 
and  II  systems  are  primarily  fixed  base  information-handling  systems 
utilizing  fixed  plant  communications,  which  are  based  typically  on 
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commercially  available  products  although  they  may  be  modified  or 
adapted  to  meet  unique  DoD  requirements  for  reliability,  survivability, 
or  communication  security.  Type  I systems  may  involve,  in  addition, 
mobile  elements  such  as  the  Advanced  Airborne  Command  Post  (AABNCP) 
and  other  communication  transmission  media  such  as  communication 
satellites. [ Weapon  control,  tactical  command  and  control  and  communi- 
cation, and  intelligence  data-handling  system  applications  are 
specifically  excluded  from  consideration  in  this  study.  \ 

A.  TELEPROCESSING:  A GENERAL  OVERVIEW 

The  capabilities  potentially  available  from  teleprocessing 
portend  significant  reductions  in  the  cost  (per  function)  and  increases 
in  the  reliability  of  providing  data  processing  and  computational 
services  to  a multiplicity  of  users.  These  capabilities  are  based  on 
networks  of  distributed  data  processing  facilities  supporting  inter- 
active computation,  distributed  data  base  query  and  response,  and/or 
data  base  exchange  and  updating  functions.  Networks  that  provide 
teleprocessing  functions  imply  the  integration  of  communications  and 
data  processing  which  traditionally  have  been  designed,  developed, 
and  procured  by  separate  DoD  organizations  and  have  been  provided  by 
independent  equipment  manufacturers . 

In  the  future,  the  traditional  roles  and  interrelationships  be- 
tween communications  and  data  processing  can  be  changed  radically  by 
this  integration.  To  guide  the  probable  transition  to  greater  use  of 
teleprocessing  within  the  DoD,  parallel  changes  in  management 
approaches  and  possible  organizational  changes  are  likely  to  be 
required . 

The  communication  plant  has  evolved  independently  of  data 
processing  equipment  as  a human-oriented  voice  or  narrative  message 
interchange  mechanism.  The  need  for  standards  was  limited  to  those 
necessary  for  compatibility  among  commonly  procured  equipment. 

Implicit  in  the  design  of  the  voice  communication  plant  were  the 
assumptions  that  (1)  each  subscriber  should  be  capable  of  communicating 
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with  any  other  subscriber  and  (2)  the  time  of  communication  was  rela- 
tively short  and  infrequent.  This  has  led  to  the  development  of  the 
present  subscriber-oriented,  common-user,  switched  telephone  networks 
with  the  concept  of  achieving  cost  savings  through  the  sharing  of 
transmission  and  switching  facilities  (economies  of  scale).  Similarly, 
the  narrative  message  communication  plant,  to  a large  extent  utilizing 
the  transmission  facilities  of  the  telephone  plant,  has  been  based  on 
(1)  non- interactive  one-way  narrative  communications  between  sub- 
scribers, (2)  relatively  short  messages,  and  (3)  message  delivery 
times  of  tens  of  minutes  to  hours.  This  has  resulted  in  the  present 
communication-center-oriented,  message-switching  networks  with 
economies  of  scale  being  achieved  through  centralized  switching  and 
shared  transmission  facilities  (including  those  shared  with  the  tele- 
phone plant)  (Section  VI -A). 

The  implicit  extension  of  these  assumptions  and  concepts  as  the 
"ultimate"  approach  to  data  communications  for  teleprocessing  systems 
may  not  be  technically  necessary  nor  economically  justified.  Further, 
the  complex  interprocess  logical  relationships  among  data  processing 
equipment,  the  operating  and  applications  programs,  and  the  remote 
data  terminal  equipment  will  strongly  influence  communication  system 
design  and  standards  and  will  require  that  approaches  other  than  those 
above  be  considered. 

In  contrast  to  the  "common-user"  concept  of  communications,  data 
processing  systems  have  evolved  as  independent  stand-alone  "batch" 
systems  or  more  recently  as  centralized  "remote- job-entry"  or  "time- 
sharing" systems  serving  small  communities  of  users  with  common 
purposes.  This  diversified  approach  has  been  fostered  by  the  equip- 
ment manufacturers  in  the  way  they  have  designed  and  marketed  their 
products.  As  a result,  standards  on  data  processing  equipment, 
communication  interfaces,  and  software  interi  j erability  only  exist 
within  a given  manufacturer's  product  line  or  within  a given  user’s 
system  when  special  interoperability  facilities  have  been  developed. 
Information  interchange  standards  applicable  to  different  manufacturers' 
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equipment  are  limited  to  standard  codes  and  their  representation  on 
various  recording  media  or  communication  channels  and  have  not  been 
implemented  on  all  equipments.  Standards  on  software  facilities, 
operating  systems,  "job  control”  languages,  and  data  managonent 
systems  are  nonexistent  except  for  certain  programming  languages 
(Sections  VII-B  and  VIII -A  and  -G). 

Therefore,  a common-user  teleprocessing  network,  utilizing  data 
processing  equipment  and  software  from  different  manufacturers  and 
truly  transparent  to  the  user,  is  not  feasible  unless  a sufficiently 
large  group  of  users  enforce  a common  base  of  software  development 
and  equipment  interoperability  standardization. 

While  the  current  general  communications  environment  is  dominated 
by  the  characteristics  of  the  existing  analog  telephony  transmission 
plant  and  the  tariff  structure  of  the  Common  Carriers,  new  Specialized 
Carriers  are  being  encouraged  to  offer  communication  services  by  a 
regulatory  policy  favorable  to  developing  market  competition.  The 
Value  Added  Networks  (VANs),  a class  of  Specialized  Carriers,  are  pro- 
ceeding with  development  of  subscriber-oriented  common-user  switched 
data  networks  based  on  adding  special  nodal  computer-based  switching 
facilities  to  dedicated  transmission  facilities  leased  from  the  Common 
Carriers.  To  varying  degrees  these  networks  are  derived  from  ARPANET 
packet- switched  technology.  The  principal  immediate  effect  of  the 
Specialized  Carriers  will  be  accelerated  reductions  in  the  tariff  rate 
structure  for  data  transmission  as  already  manifest  in  the  newly 
proposed  AT&T  Hi/Lo  density  tariff  changes  (Section  VI-A). 

Also,  the  introduction  of  the  new  AT&T  leased  point-to-point 
Digital  Data  Service  (DDS)  utilizing  all  digital  T-l  local  circuits 
and  Data  Under  Voice  (DUV)  can  be  expected  to  further  the  trend  toward 
restructured  and  reduced  transmission  costs.  Of  even  greater  signi- 
ficance would  be  the  introduction  of  switching  services  (possibly 
logical  or  fast-circuit  switching)  on  the  DDS  (the  possibility  of  DDS 
switched  service,  while  feasible,  is  purely  speculative  and  there  has 
been  no  formal  indication  by  AT&T  that  the  introduction  of  switched 


service  is  planned).  A switched  DDS  could  provide  a low-cost 
subscriber-oriented  common-user  data  network  of  considerable  geographic 
coverage  and  capacity  that  would  have  major  impact  on  the  general 
competitive  evolution  of  the  data  communications  market,  user  tele- 
processing planning  activities,  and  the  development  of  both  hardware 
and  software  technology  (Section  VI-A). 

Overall,  the  future  communications  environment  is  thus  charac- 
terized by  uncertainty;  the  outcome  of  competing  new  types  of  service, 
their  geographical  extent,  and  the  magnitude  of  the  downward  trend  in 
communication  transmission  costs  and  tariffs  cannot  be  predicted. 
Moreover,  the  possible  future  introduction  by  AT&T  of  switched  service 
in  the  DDS  could  have  a profound  impact  on  the  development  of  tele- 
processing technology  and  on  the  decisions  to  implement  dedicated 
versus  common-user  networks. 

Finally,  the  major  data  processing  equipment  manufacturers  per- 
ceive teleprocessing  as  a major  new  market  area  and  are  investing 
hundreds  of  millions  of  dollars  in  independently  developing  the  equip- 
ment and  software*  to  support  this  capability.  The  smaller  or 
specialized  suppliers  are  paralleling  these  developments  to  maintain 
their  competitive  positions.  In  addition,  comparable  amounts  are 
being  invested  in  the  new  communication  services,**  signaling  a major 
expansion  of  the  data  communication  plant.  These  developments,  the 
industry  pressures  to  rationalize  interoperability  requirements,  and 
a renewal  of  the  Federal  Government’s  efforts  (NBS  and  GSA)  to 
establish  standard  peripheral  equipment  interfaces  will  guide  the 
industrywide  development  of  new  processing,  communication  and  terminal 


IBM’s  ’’Advanced  Function  for  Communications’’  and  "Systems 
Network  Architecture"  for  the  370  series  computers  and 
CDC’s  CYBER  170  series  "Network  Operating  System"  and 
"Network  Communication  System,’’  for  example. 

** 

AT&T’s  Digital  Data  Service  and  the  various  Value 
Added  Networks  and  other  Specialized  Carriers. 
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equipment  and  standards,  and  will  shape  the  form  of  data  processing 
and  communication  systems  available  to  the  DoD  for  future  implementa- 
tions . 

The  magnitude  of  the  commercial  investments  and  the  probable 
future  DoD  budget  restrictions  will  result  in  DoD  maximizing  its  use 
of  these  commercial  products  insofar  as  they  can  satisfy  its  tele- 
processing requirements.  To  assure  adequate  consideration  of  its 
unique  requirements  and  to  minimize  the  extensive  and  recurring  costs 
of  modifying  its  future  data  processing  systems  to  meet  these  require- 
ments, DoD  will  probably  have  to  actively  participate  in  the  develop- 
ment of  industry  data  communication  standards  (much  as  it  did  for  the 
COBOL  standard). 

B.  DoD  TELEPROCESSING  APPLICATIONS 

To  provide  a framework  for  considering  teleprocessing  system 
needs  and  issues  within  the  DoD,  this  study  has  identified  the  major 
application  areas  as  follows: 

• Type  la  - Command  and  Control  of  Nuclear  Forces 

lb  - Nonnuclear  Crisis  and  Contingency  Command 
and  Control 

• Type'll  - General  Data  Processing  Services 

Type  I applications  are  aimed  at  informational  support  of  the  National 
Command  Authorities  (NCA)  and  supporting  commands  with  major  support 
from  the  World  Wide  Military  Command  and  Control  System  (WWMCCS). 

Type  II  applications,  on  the  other  hand,  are  diversified  being  oriented 
toward  the  provision  of  data  processing  and  computational  services  to 
administrative,  service,  and  other  organizations  within  the  DoD 
(Section  III -A). 

Type  la  applications  must  emphasize  survivable  connectivity  be- 
tween higher  level  command  authorities  and  the  nuclear-capable  forces 
through  the  transattack  period.  Typically,  there  is  a minimal  volume 
of  essential  command  data  with  assured,  rapid,  and  secure  delivery  of 
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these  data  being  the  primary  goal.  Cost  and  economical  operation 
tend  to  be  secondary  to  these  goals.  Systems  supporting  this  appli- 
cation area  include  SATIN  IV  (SAC  Automated  Total  Information  Network), 
the  present  and  Advanced  Airborne  Command  Post  (AABNCP)  aircraft, 
supporting  communications  (AFSATCOM,  PACCS,  MEECN,  EMATS,  and  others), 
and  other  selected  elements  of  the  WWMCCS  [the  National  Military 
Command  System  (NMCS)]  that  may  survive  (Section  III-B). 

Type  lb  applications  are  characterized  by  intermittent  large 
data  processing  and  communication  demands  without  a priori  knowledge 
of  where  or  when  such  capacity  will  be  needed  or  specifically  what 
data  will  be  required.  The  major  goal  of  these  applications  is  the 
need  to  rapidly  locate,  correlate,  process,  and  display  quantities  of 
data,  geographically  and  organizationally  distributed,  for  contingency 
planning  and  general-purpose  force  control.  Survivability  require- 
ments are  lower  while  communication  and  multilevel  data*  security  is 
a major  concern  and  cost  tends  to  be  of  equal  concern.  The  WWMCCS  is 
the  primary  system  supporting  this  application  with  various  specialized 
and  common-user  supporting  communications . While  the  WWMCCS  is  not 
currently  a texeprocessing  system,  various  data  communication  programs 
such  as  the  Prototype  WWMCCS  Intercomputer  Network  (PWIN),  the  WWMCCS 
Internet  (WIN),  and  AUTODIN  II  are  being  considered  or  are  in  develop- 
ment for  interconnecting  the  WWMCCS  computer  facilities  (Section  III-B). 

Type  II  applications  in  the  DoD  are  extremely  varied  and  analogous 
to  many  commercial  applications  of  teleprocessing  such  as  Management 
Information  Systems,  Time  Sharing,  Remote  Entry  Service  Bureaus,  and 
others.  In  these  applications,  the  overriding  consideration  is  the 
economic  delivery  of  data  processing  and  computational  services.  Also 
in  some  systems  security,  both  communication  security  (ComSec)  and 
multilevel  data  security,  may  be  major  requirements.  While  few,  if 
any,  true  Type  II  teleprocessing  systems  currently  exist  within  the 


The  control  of  access  by  users  of  differing  levels  of 
clearance  to  a system  (computer)  containing  data  of 
various  security  levels. 
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DoD,  every  major  service  or  joint  reporting  system  is  a potential 
candidate  for  the  application  of  teleprocessing.  Illustrative  of  the 
potential  is  the  Air  Force  SADPR-85  Base  Level  Computer  Network 
Concept,  a possible  future  dedicated  teleprocessing  network  intended 
to  consolidate  present  Air  Force  Base  Level  ADP  activities  into  11 
regional  centers.  The  DCA  proposed  AUTODIN  II  (an  upgraded  replace- 
ment for  the  current  AUTODIN,  a store-and-f orward  narrative  message 
switching  system)  is  an  example  of  a computer  subscriber-oriented 
common-user  switched  data  transmission  system  for  supporting  tele- 
processing systems  (Section  III-C). 

C.  ISSUE:  DEDICATED*  VERSUS  COMMON-USER**  TELEPROCESSING  NETWORKS 

Because  of  differing  requirements,  the  diff icult-to-predict 
future  technological  and  cost  environment,  and  the  lack  of  effective 
analytical  tools  and  supporting  data,  there  does  not  appear  to  be  any 
"best"  technical  or  cost-effectiveness  approach  to  provide  teleprocess- 
ing services  to  the  various  communities  of  users  within  the  DoD. 

Type  I applications  will  probably  continue  to  develop  along  dedicated 
system  lines  because  of  their  importance,  time  schedules,  and  unique 
requirements.  Type  II  applications  will  probably  be  aggregated  along 
several  lines  simultaneously:  by  organization  (SADPR  or  MAC 


A dedicated  network  implies  a system  that  (1)  is  devoted 
(usually  full  time)  to  a well-defined  set  of  functions 
serving  a homogeneous  group  of  users,  (2)  provides  only 
fixed  interconnections  among  users,  and  (3)  is  usually 
optimized  or  specialized  (in  equipment  configuration, 
communications,  processors,  software,  terminals,  etc.) 
for  the  given  purpose. 

Sr 

A common-user  network  implies  a system  that  (1)  serves 
(usually  on  demand)  a heterogeneous  group  of  users  with 
varying  functional  requirements,  (2)  provides  for  arbitrary 
interconnections  among  users,  and  (3)  usually  must  accommo- 
date a wide  variety  of  user  equipment  configurations  and 
interface  standards  (communications,  processors,  software, 
terminals , etc . ) . 


i1 
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Information  Management  System),  by  geographical  region  (Navy  Data 
Processing  Service  Center  or  Army  Northeast  Computer  Center),  or  by 
standard  application  [Joint  Uniform  Military  Personnel  Systems  (JUMPS)]. 
Data  communications  for  both  classes  of  applications  may  be  provided 
either  as  a dedicated  communication  network  (with  some  means  of  inter- 
connection and  interoperability)  or  as  a part  of  a common-user 
network.  The  major  considerations  will  be  cost  and  the  interoperability 
of  the  various  data  processing  systems  comprising  a network  (Sections 
III-B  and  -C). 

1.  Network  "Economies  of  Scale” 

A common-user  data  communication  system  with  complete  connectivity 
among  all  DoD  users  (Type  I and  II  applications)  may  not  be  an 
attractive  DoD  approach  for  meeting  its  teleprocessing  needs  since  it 
does  not  appear  that  the  economies  of  scale  persist  to  very  large  data 
communication  systems.  This  is  based  in  part  on  a comparison  of  an 
early  DC A AUTODIN  II  study  (Ref.  1),  and  the  communication  portion  of 
the  more  recent  Air  Force  SADPR  study  (Ref.  2),  and  in  part  on  a study 
done  for  the  Office  of  Telecommunications  Policy  (Ref.  3).* 

The  AUTODIN  II  and  SADPR  networks  proposed  in  the  above  studies 
are  qualitatively  similar  in  having  comparable  geographic  coverage, 
high-speed  communication  trunks,  and  packet  switching.  The  AUTODIN  II 
(Section  III-C-5)  is  by  far  the  higher  capacity  system,  being  intended 


to  interconnect  160  major  computer  sites  while  the  SADPR  communication 
system  (Section  III-C-4)  is  intended  to  interconnect  11  major  Air  Force 


computer  sites.  Using  ten-year  costs  (leased  circuit,  switches  on 
rental  or  tariff  bases,  and  O&M  costs)  and  neglecting  communication 
security  (ComSec)  equipment  and  O&M  costs,  the  average  communication 
cost**  (for  comparable  capabilities ) for  both  approaches  is  about 
$650  thousand  per  major  site  per  year  (Table  7,  page  78).  When  the 
costs  of  conventional  communication  security  equipment  and  O&M  are 

*The  costs  obtained  from  these  studies  have  not  been  independently 
verified. 

** 

Total  annual  communication  cost  divided  by  the  number  of  major 
ADP  sites. 
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considered,  the  SADPR  projected  costs  are  $1300  thousand  per  major 

/ 

site  per  year,  and  the  AUTODIN  II  projected  costs  are  $800  thousand 
per  major  site  per  year.  If  the  largest  portion  of  the  ComSec  costs, 
the  O&M  costs,  could  be  eliminated  (on  presumption  that  EATTON 
technology  will  be  available)  or  shared  with  other  O&M  functions, 
there  would  not  appear  to  be  significant  saving  that  could  be  attrib- 
uted to  economies  of  scale  of  the  AUTODIN  II  over  that  of  the  SADPR 
communication  system  (Section  III-C). 

Further,  in  comparison  with  a centralized  switching  concept  (such 
as  AUTODIN  II),  data  processing  system  centered  data  networks  (as 
illustrated  by  SADPR)  are  attractive  for  several  additional  reasons. 
Essentially  all  communication  distribution,  switching,  and  control 
functions  are  performed  at  the  data  processing  equipment  site,  reducing 
the  need  for  separate  switching  facilities  and  providing  a greater 
sharing  of  O&M  costs  among  subsystem  functions.  Also,  the  whole 
teleprocessing  system,  excluding  the  ComSec  equipment  and  communica- 
tion transmission  facilities , are  under  the  control  of  the  sponsoring 
organization  making  the  system  more  responsive  to  user  needs,  providing 
greater  assurance  of  compatibility  and  reducing  procurement  and  O&M 
costs  by  greater  use  of  the  single  computer  supplier’s  equipment  and 
software.  In  addition,  the  investment  in  the  dedicated  communication 
system  need  not  be  made  until  the  data  processing  system  is  justified, 
procured,  and  installed,  rather  than  to  require  the  large  initial 
investments  in  communication  equipment  and  separate  facilities 
implicit  in  providing  a centrally  switched  common-user  system  prior 
to  significant  teleprocessing  system  implementations  (Section  III-C). 

Finally,  the  study  for  the  Office  of  Telecommunications  Policy 
also  indicates,  based  on  a sizing  and  cost  model,  some  of  the  factors 
influencing  economies  of  scale.  In  one  case,  a highly  centralized 
system  serving  the  50  major  U.S.  cities  and  providing  primarily 
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message  switching  function  with  a small  amount  of  remote  batch  opera- 
tions, long-distance  communication  unit  costs*  decreased  almost 
linearly  with  increased  load  level  but  never  exceeded  15  percent  of 
total  system  cost.  The  total  system  unit  costs  were  dominated  by  the 
central  station  and  terminal,  modem  and  local  loop  unit  costs.  In  a 
second  example,  also  a centralized  system  with  similar  geographic 
coverage  providing  comparable  levels  of  message  switching,  inquiry, 
order  entry  and  remote  batch  functions,  communication  unit  costs 
dominated  (40  percent  of  total  unit  costs)  at  low  levels  of  trans- 
actions. At  higher  load  levels,  communication  unit  cost  decreased  to 
below  15  percent  with  central  systems  and  terminals  again  dominating 
total  system  unit  costs.  A final  example  shows  that  at  low  load 
levels  the  communication  unit  costs  of  independent  networks  may  be  as 
[ | much  as  six  times  greater  than  for  a shared  network  of  equal  total 

level  of  output,  and  at  higher  load  levels  the  communication  unit 
costs  are  comparable,  but  in  either  case  the  unit  costs  are  a small 
E i fraction  (25  percent  decreasing  to  10  percent)  of  total  system  unit 

costs  (Section  III-C-6). 

While  the  DCA  AUTODIN  II  and  SADPR  cost  estimates  above  are  only 
S • illustrative  and  subject  to  further  study  and  refinement,  they  and 

; the  OTP  Study  are  indicative  that  data  networks  dedicated  to  a 

community  of  users  may  be  a viable  and  economical  alternative  to  a 
single  large  subscriber-oriented  common-user  data  network.  If  inter- 
community communications  are  necessary,  the  adoption  of  compatible 
standards  could  permit  the  interoperability  and  exchange  of  information 

| i 

between  these  dedicated  networks. 
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CONCLUSION: 


(1)  A viable  alternative  to  a subscriber-oriented 
common-user  data  network,  at  least  for  an  interim 
period,  could  be  community-dedicated  communica- 
tion networks  scaled  to  the  requirements  of  a 
community  of  users  and  procured  and  implemented 

at  the  time  the  individual  data  processing  systems 
are  installed.  Common  provision  of  transmission 
facilities  through  DCA  could  still  be  used. 

(2)  However,  ComSec  O&M  costs  appear  to  be  a dominant 
factor  which  will  weigh  heavily  against  the  use 
of  smaller  dedicated  networks  unless  programs 
such  as  EATTON,  intended  to  significantly  reduce 
these  costs,  are  implemented. 

2 . Data  Processing  System  Interoperability 

A deeper  and  more  pervasive  problem  in  the  successful  utilization 
of  a common-user  teleprocessing  network  arising  from  the  experimental 
WWMCCS  network  experience  is  the  problem  of  standard  operating  systems 
and  support  software  (particularly  data  base  management  systems),  and 
modular  system- transferable  applications  software.  Given  the  estab- 
lishment of  a communication  link  between  a user  and  a remote  data  base 
in  a different  organization,  unless  the  user  knows  the  standards,  the 
language,  the  means  of  operating  the  software,  and  the  very  meaning 
of  the  data  elements,  he  cannot  effectively  obtain  and  utilize  infor- 
mation. Thus  a common-user  teleprocessing  network  requires  widespread 
information  standardization  if  successful  interchange  is  to  be  achieved. 
While  such  standardization  is  conceivable  in  the  relatively  small 
community  of  users  such  as  WWMCCS,  the  extension  to  all  potential 
data  base  systems  that  a (WWMCCS)  user  may  need  access  to  implies  a 
level  of  data  and  software  standardization  across  all  major  computer 
manufacturers'  product  lines  that  has  never  been  achieved  before.  To 
achieve  this  level  of  standardization  in  the  computer  industry  is 
difficult  because  there  is  little  or  no  incentive  for  the  manufacturers 
to  be  compatible  with  their  competitors  (Section  VIII-G). 


13 


CONCLUSION: 
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Differences  in  manufacturers'  software  and  user- 
defined  application  programs  or  data  elements 
will  limit  the  interoperability  of  teleprocessing 
systems  and  require  major  and  costly  standardiza- 
tion and  modification  programs  to  achieve 
compatibility. 

3 . A Suggested  Interim  Approach 

From  the  foregoing,  the  establishment  of  a common-user  tele- 
processing network  may  not  be  economically  attractive  nor  achievable 
in  the  next  several  years  because  of  the  difficulties  of  establishing 
operating  system  and  service  software  standards.  If  necessary,  DoD 
could  identify,  as  an  interim  measure,  major  communities  of  users  who 
must  communicate  and  share  data  within  each  community  to  speed  the 
development  of  requirements  and  the  planning  for  system  implementation. 
These  communities  might  typically  be  the  WkMCCS , the  component  command 
C&C  systems,  the  intelligence  community,  the  Services'  management 
information  systems,  and  others.  These  communities  will  often  cut 
across  conventional  organizational  lines  (Section  III-C). 


CONCLUSION: 

(1)  If  this  interim  approach  is  considered,  DoD 
should  identify  organizations  to  be  responsible 
for  commonality  and/or  interoperability  of  equip- 
ment and  software,  data  base  standardization,  and 
the  economic  provision  of  data  communication 
services  within  these  communities. 

(2)  Further,  DoD  should  identify  an  organization 
responsible  for  coordinating  these  communities, 
particularly  in  the  areas  of  standards  and  the 
provision  of  data  communication  services  to 
minimize  the  potential  interoperability  problems 
if  larger  aggregations  of  users  were  to  develop 
in  the  future. 


\ 
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D.  ISSUE:  CURRENT  TELEPROCESSING  DEVELOPMENTAL  PROGRAMS 

The  current  DoD  developmental  teleprocessing  system  programs* 
provide  indications  of  the  types  of  problems  that  can  occur  in 
developing  and  implementing  teleprocessing  systems  without  appropriate 
intersystem  standards  and  operating  procedures.  The  difficulties  that 
arise  from  establishing  the  interoperability  of  SATIN  IV,  the  AABNCP , 
and  the  WWMCCS  computers  are  caused  in  part  by  the  differing  interface 
and  interprocess  standards  (protocols)  and  communication  links  used 
in  the  various  systems.  The  PWIN  experimental  program  for  inter- 
connecting the  computers  at  JTSA,  NMCSSC , and  CINCLANT,  and  the 
program  for  transferring  FORSTAT  processing  and  updates  have  resulted 
in  the  need  for  significant  modifications  of  the  WWMCCS  computer 
operating  system  and  communication  equipment  and  software.  While 
some  of  these  problems  are  magnified  by  the  use  of  current  teleprocess- 
ing technology,  equipment  and  software,  the  impact  (costs,  implementa- 
tion delays,  equipment  and  software  modifications,  limited  inter- 
operability) on  future  attempts  to  interconnect  different  systems 
(particularly  from  different  manufacturers  with  independently  developed 
and  specified  data  communication  systems)  will  be  extensive.  These 
developmental  programs  are  necessary  to  develop  the  experience  and 
understanding  of  implementation  problems  necessary  for  future 
successful  applications  of  teleprocessing  within  the  DoD.  Particularly, 
the  assessment  of  the  adequacy  of  current  software  approaches  for 
supporting  a computer-communication  environment  and  of  the  adequacy 
of  packet  switching  (ARPANET  technology)  in  an  operational  command 
and  control  environment  will  be  invaluable  in  future  designs 
(Section  VIII). 


The  interconnection  of  SATIN  IV,  the  AABNCP,  and  the  WWMCCS 
computers  at  the  ANMCC  and  NMCSSC ; the  interconnection  of 
the  WWMCCS  computers  at  the  JTSA,  NMCSSC,  and  CINCLANT 
through  PWIN ; and  the  interconnection  of  the  WWMCCS  com- 
puters at  the  ANMCC  and  NMCSSC  for  transferring  FORSTAT 
processing  and  updates. 
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CONCLUSION: 


(1)  Pursuit  of  these  developmental  programs,  even 
though  the  interface  standards  and  interprocess 
procedures  established  may  be  changed  in  the 
future,  would  help  develop  the  experience  and 
understanding  necessary  to  the  development  of 

a better  and  more  cohesive  approach  for  tele- 
processing within  DoD. 

(2)  While  DoD  should  continue  to  cooperate  with  and 
encourage  commercial  standards  groups  as  it  has 
in  the  past,  the  urgency  of  the  present  develop- 
mental programs  requires  independent  establish- 
ment of  interim  DoD  standards  as  soon  as  possible. 

E.  ISSUE:  TELEPROCESSING  NETWORK  STANDARDS 

Typically,  data  communications  for  commercial  teleprocessing 
systems  represent  10  percent  to  20  percent  of  total  system  cost. 

Of  the  remaining  data  processing  costs,  industry  estimates  indicate 
that  75  percent  is  for  software  (operating  systems,  supporting 
system  programs,  communication  control,  data  base  management,  and 
applications  programs).  A significant  portion  of  these  costs, 
particularly  in  the  new  teleprocessing-oriented  commercial  computer 
systems,  is  for  the  unique  software  operating  systems  and  communi- 
cation control  programs  provided  by  the  manufacturer  with  his 
equipment.  This  software  is  supported  (upgraded,  maintained,  and 
corrected)  by  the  manufacturer  who  is  able  to  amortize  the  large 
development  investments  necessary  over  the  large  number  of  systems 
installed. 

If  the  commercially  available  data  processing  systems  are 
incompatible  with  DoD  data  communication  equipment  and  standards, 

DoD  must  accept  the  burden  of  modifying  and  supporting  the  operating 
systems  and  communication  control  programs  during  a system’s  life- 
time. A recent  study  (Ref.  4)  indicates  that  the  total  current 
annual  DoD  software  costs  are  exceeding  $3  billion  and  reported 
that  other  studies  have  indicated  that  an  estimated  85  percent  to 
95  percent  of  the  WWMCCS  ADP  costs  are  for  software.  For  the 


future,  to  minimize  its  development  and  O&M  investments  in  equipment 
and  software  modification  and  maintenance,  it  would  appear  that  DoD 
should  consider  adapting  its  requirements  for  teleprocessing  systems 
to  the  developing  industrywide  system  standards.  However,  these 
standards  probably  do  not  accommodate  the  unique  DoD  requirements 
for  communication  security  (ComSec),  access  control,  multilevel  in- 
formation (data  base)  security,  system  priority  overrides  to  meet 
peak  demand,  system  redundancy,  and  system  survivability. 

CONCLUSION: 

(1)  For  the  future,  DoD  should  consider  adopting 
industry  data  communication  standards  to  avoid 
the  extensive  and  continuing  additional  costs 
of  modifying  commercial  data  processing  systems 
to  meet  differing  communication  standards. 

(2)  DoD  should  also  consider  actively  fostering 
and  participating  in  the  development  of 
industrywide  data  processing  and  data  communi- 
cation standards  to  provide  the  greatest 
availability  of  compatible  and  competitive 
equipment  and  software  for  future  system 
implementations,  to  maximally  utilize  the  very 
large  industry  investments  (potentially 
hundreds  of  millions  of  dollars)  in  equipment 
and  software,  and  to  assure  adequate  considera- 
tion of  unique  DoD  requirements. 


F.  ISSUE:  MULTILEVEL  SECURITY* 

Multilevel  security  is  an  essential  element  for  DoD  tele- 
processing systems.  There  is  currently  no  known  method  to  provide 
’’adequate”  security  for  teleprocessing  systems.  Moreover,  no 
rigorous  method  has  been  found  acceptable  for  proof-testing  secure 
teleprocessing  systems.  In  such  systems  it  is  necessary  to  differ- 
entiate between  subscriber  host/computer  security  and  security  in 
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The  control  of  access  by  users  of  differing  levels  of 
clearance  to  a system  (computer)  containing  data  of 
various  security  levels. 
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the  switched  data  transmission  facilities.  Since  transmission  link 
security  has  been  achieved  and  switching  facilities  utilize  limited 
and  specific  computer  functions  which  can  be  hardware  compartmented 
and  housed  in  secure  facilities,  it  is  reasonable  to  expect  that 
switched  data  transmission  security  can  be  achieved.  The  provision 
of  multilevel  security  for  teleprocessing  host  computers  is  more 
difficult  and  further  in  the  future.  Research  activities  are  under 
way  with  the  virtual  machine  and  security  kernel  being  the  most 
promising  approaches  being  pursued  (Section  VII-E) . 

In  the  relationship  between  transmission  security  and  subscriber 
host/computer  security,  it  is  obviously  not  sufficient  to  have  one 
without  the  other  or  to  overinvest  in  achieving  one  at  the  expense 
of  the  other.  Even  more  fundamental  is  the  likelihood  that  while 
security  may  be  achieved  for  transmission  and  host  sites  individually, 
when  they  are  interconnected  in  a teleprocessing  network,  security 
may  not  be  assured.  As  a result,  there  is  a need  to  develop  methods 
to  verify  that  in  a teleprocessing  network  an  adequate  level  of 
security  has  been  achieved.  It  seems  certain  that  new  concepts  of 
security  and  resulting  doctrine  will  have  to  be  evolved.  Due  to  the 
fundamentally  new  features  (technical,  operational,  and  organizational) 
of  teleprocessing  systems,  multilevel  security  requirements  will  have 
a major  impact  on  the  access  that  various  users  will  have  to  certain 
systems  and  on  systems  design  and  implementation  (Section  VII-E). 

CONCLUSION; 

(1)  The  development  of  solutions  to  the  multilevel 
security  problems  and  the  establishment  of  new 
security  procedures  for  teleprocessing  systems 
should  be  pursued  to  assure  that  an  ’’adequate" 
level  of  multilevel  computer  data  security  can 
be  obtained  and  shown  to  exist  when  a multi- 
plicity of  systems  are  connected  together  in  a 
network . 


(2)  New  security  equipment  and  procedures  are  also 
required  because  the  application  of  current 
approaches  increases  the  costs  to  a level  that 
the  projected  economies  of  teleprocessing 
systems  are  minimized  or  lost. 


G.  ISSUE:  NETWORK  SWITCHING 

Comparisons  between  packet-  and  circuit-switching  networks  are 
a function  of  user  characteristics,  types  of  data  (transmission, 
bulk),  load  level,  and  geographic  distribution  (as  well  as  being 
sensitive  to  the  technology,  cost,  and  comparison  measures  chosen). 
The  principal  advantage  of  the  packet  technique  derived  from  the 
ARPANET  program  resides  in  its  flexible  dynamic  allocation  of 
communication  transmission  trunks  and  potentially  high  utilization 
of  overall  network  capacity  on  a nearly  instantaneous  demand  basis. 
This  technique  is  of  particular  advantage  for  interactive  and  data 
base  query  response  teleprocessing  applications.  In  addition,  a 
multiplicity  of  dispersed  switching  locations  utilizing  packet 
switching  with  adaptive  routing  provides  enhanced  survivability  of 
communications  connectivity.  However,  packet  switching  does  require 
standardized  data  interfaces  since  switching  is  a logical  function 
performed  within  a computer-like  device.  Also,  packet-switching 
network  flow  control  with  priority  preempts,  a major  requirement  in 
DoD  data  communication  networks,  is  not  well  understood  (Sections 
V-C  and  VII-C). 

On  the  other  hand,  for  bulk  data  transmission  such  as  data  base 
transfers  and  remote  job  entry,  circuit  switching  has  the  advantage. 
Circuit  switching  is  more  efficient  and  much  more  flexible  since 
once  the  switching  function  is  performed,  the  circuit  is  completely 
transparent  to  the  data  stream.  Also,  preemption  techniques  and 
means  of  enhancing  connectivity  survivability  are  better  understood 
based  on  the  approaches  used  in  the  AUTOVON  voice  network  (Sections 
V-C  and  VII-C). 

However,  a third  alternative  is  to  remove  the  switching  from 
the  communication  network  and  provide  dedicated  trunks  between  data 


processing  sites  and  perform  the  switching  in  the  processors.  While 
this  may  increase  the  costs  of  communications  if  the  dedicated  trunks 
are  not  fully  utilized,  the  introduction  of  concentrators  for  local 
access  lines  can  provide  dynamic  sharing  of  the  trunks  which  will 
realize  the  major  portion  of  the  savings  on  long-distance  point-to- 
point  transmissions  cost.  This  approach  does  not  provide  the  on- 
demand  connectivity  between  arbitrary  points  (the  forte  of  the 
common-user  switched  data  network),  but  it  can  provide  economical 
service  for  fixed  connectivity  systems  if  the  trunks  can  be  reasonably 
utilized.  An  extension  of  this  concept  to  more  fully  utilize  the 
trunks  is  a piggyback  communications  service  that  could  be  provided 
by  a large  geographically  distributed  teleprocessing  system  to 
smaller  local  systems  with  limited  long-distance  communication 
requirements  (Sections  V-B  and  -C). 


CONCLUSION : 

(1)  While  both  packet  technology  and  circuit 
switching  appear  attractive,  a hybrid  packet 
and  circuit- switch  design  may  be  the  most 
desirable  approach  for  segregating  bulk  data 
transmissions  from  transactional  data  inter- 
changes, mitigating  the  access  and  flow  control 
problem,  and  achieving  flexible  reconfiguration 
of  the  network  to  changes  in  user  characteristics . 

(2)  The  use  of  a centralized  processor  (with  its  own 
communication  processor)  of  a given  system  to 
concentrate  and  relay  information  or  requests 
from  its  community  of  users  to  another  system 
could  minimize  the  requirements  for  a subscriber- 
oriented  common-user  switched  data  network. 

(3)  Analysis  is  required  to  determine  whether  (1)  a 
centralized  switching  concept  such  as  AUTODIN  II, 
or  (2)  a concept  of  distributed  switching  collo- 
cated with  major  data  processing  centers  such  as 
ARPANET,  or  (3)  a data  processing  system  centered 
data  network  using  full-time  dedicated  trunks 
(with  simple  multiplexing/concentration  for  line 
sharing),  or  (4)  an  appropriate  mix  of  these  con- 
cepts, is  the  more  economical. 


20 


* 

.1 


H.  ISSUE:  TELEPROCESSING  NETWORK  REQUIREMENTS  AND  ANALYSIS 

At  present,  teleprocessing  requirements  formulation  is  done  on 
a system-by-system  basis,  a reasonable  process  compatible  with  up- 
grading present  stand-alone  systems  but  inadequate  for  any  overview 
of  aggregated  teleprocessing  requirements . However,  as  part  of  the 
DTACCS  Internet  Study  (Ref.  5),  a re-examination  of  the  DoD  candidate 
teleprocessing  systems  was  conducted.  This  provided  for  the  first 
time  in  DoD  a common  frame  of  reference  for  preparing  teleprocessing 
system  descriptions  and  requirements.  Without  such  a requirements 
overview  it  is  very  difficult  to  assess  the  present  status  and 
projected  teleprocessing  needs  nor  make  judgments  as  to  priority  of 
need.  Functional  ADP  systems  data  also  have  been  collected  and 
aggregated  by  OASD  (I&L)  and  were  used  in  the  DTACCS  Internet  Study 
(Section  IV). 

The  current  methods  of  analysis  of  data  processing  requirements 
are  inadequate  for  teleprocessing  systems  because  they  tend  to 
neglect  the  detailed  interaction  between  data  processing  and  communi- 
cations, the  communication- induced  processing  workloads,  and  the 
tradeoffs  in  types  of  equipment  and  allocations  of  processing  among 
sites.  As  more  comprehensive  data  are  obtained  describing  user- 
oriented  data  processing  requirements,  it  will  be  necessary  to 
translate  these  needs  into  technical  specifications  of  generic  types 
of  basic  processor  functions  and  relate  these  to  the  division  of 
tasks  among  processor  sites,  to  communications  traffic  loads,  and 
to  network  organization.  Mathematical  models  of  user  activity, 
computer  functions,  and  data  organization  and  traffic  will  have  to 
be  developed  or  refined  (Sections  V-A  and  VII-A). 

In  addition  to  the  limitations  of  available  design  and  analysis 
techniques,  system  costs  are  sensitive  to  the  complex  schedules  of 
transmission  tariffs  and  equipment  charges  developed  within  the  con- 


text of  current  use  of  the  telephone  plant  as  a support  element  to 
computer  centers.  As  such,  the  analysis  is  specialized  by  and  the 
results  limited  to  the  particular  configuration  and  operational 
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constraints  of  specific  vertically  integrated  systems.  Only  recently, 
as  an  outgrowth  of  ARPANET,  are  analytical  design  tools  being  evolved 
that  are  applicable  to  the  study  of  subscriber-oriented  data  net- 
works (Section  VII -A) . 

Network  control  design  problems  also  exist.  Only  since  the 
advent  of  the  ARPANET,  PWIN,  AUTODIN  II,  and  the  interconnect  on  be- 
tween SATIN  3V  and  AABNCP  has  the  magnitude  of  the  network  inter- 
connection problem  become  apparent.  Currently  there  is  an  inadequate 
understanding  of  the  problems  of  flow  control,  overflow  procedures, 
failure  recovery,  access  and  priority  override  control,  and  others. 
Also,  it  can  be  expected  that  future  teleprocessing  networks  will 
develop  a need  to  interconnect  at  least  selectively  at  gateway 
locations.  This  will  involve  areas  of  additional  technical  com- 
plexity that  include  logical  compatibility,  message  responsibility, 
control  stability,  fault  recovery,  and  security.  Commitments  to 
major  new  operational  teleprocessing  systems  should  be  based  on  a 
better  understanding  of  these  problems  and  their  impact  on  network 
structure  and  requirements  (Sections  V-C  and  VII-D). 


CONCLUSION: 

(1)  Currently  there  is  no  one  element  within  DoD 
formally  charged  with  developing  and  main- 
taining a current  and  comprehensive  computer 
system  description  and  requirements  data  base 
including  teleprocessing  related  data. 

(2)  DoD  needs  to  foster  the  development  of  more 
comprehensive  methods  of  describing  system 
requirements,  and  translating  these  require- 
ments into  technical  specifications,  as  well 
as  development  of  performance  measures , net- 
work analytical  methodologies,  and  sufficient 
data  on  patterns  and  demands  of  system  usage. 
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Finally,  the  study  team,  in  judging  the  results  of  this  pre- 
liminary study,  can  only  reiterate  and  strongly  support  the 
following  conclusions  of  the  1970  Blue  Ribbon  Study.* 

The  basic  problem  is  that  the  present 
organizational  assignment  of  responsibilities 
for  ADP  policy  formulation,  management  and 
operation  is  inadequate  to  insure  the  most 
efficient  and  economical  use  of  ADP  either 
Department-wide,  or  within  a Military  Depart- 
ment or  Defense  Agency.  The  organizational 
level  of  policy  responsibility  within  the 
Office  of  the  Secretary  of  Defense  (OSD)  for 
ADP  is  too  low  to  insure  that  required  and 
desirable  policy  changes  are  made  and  imple- 
mented consistently  throughout  the  Department. 

In  addition,  there  is  no  single  office  charged 
with  the  responsibility  for  long-range  planning 
to  keep  policy  abreast  of  industry  development, 
and  to  provide  flexibility  in  Department  policy 
to  take  advantage  of  evolving  technological 
changes . 

Present  assignment  of  policy  responsibility 
for  ADP  in  OSD  takes  inadequate  cognizance  of  the 
close  technical  and  cost  relationship  of  communi- 
cations and  ADP  management.  As  a consequence, 
the  interface  between  ADP  and  communications  is 
inadequate,  and  will  become  increasingly  inadequate 
as  digital  communications  technology  increases . 

The  remainder  of  this  report  discusses  the  following  subjects: 

• Section  II — the  background  and  approach  used  in 
the  study 

• Section  III — the  generic  types  of  teleprocessing 
applications  within  DoD  with  a description  of 
several  current  proposed,  developmental,  and 
experimental  teleprocessing  systems  including 
SATIN  IV,  PWIN , SADPR-85,  and  AUTODIN  II 

• Section  IV — data  processing  requirements  and  a 
summary  of  the  current  data  processing  assets  of  DoD 
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• Section  V — design  and  architectural  considerations 

of  communication  networks  including  network  topology, 
system  sharing,  and  common-user  network  design 

• Section  VI — the  future  communication  environment 
including  new  transmission  facilities  and  suppliers 

• Section  VII — selected  system  development  issues  and 
needs  including  analytical  methodology,  network 
interface  standards,  data  switching,  network  control 
and  interconnection 

• Section  VIII — some  current  developmental  system 
experience  and  problems  related  to  interface 
standards  (protocols)  and  service  and  application 
programs  (data  base  management,  PORSTAT,  etc.) 

• Appendix  B — a data  processing  technology  forecast 
taken  from  the  SADPR-8S  study. 


II . INTRODUCTION 


A.  BACKGROUND  AND  PURPOSE 

In  October  1973,  IDA  was  requested  by  the  Office  of  the  Assistant 
Secretary  of  Defense  (Telecommunications)*  to  undertake  a task  di- 
rected toward  the  development  of  a basis  for  evaluating  the  benefits 
that  could  result  from  managing  computer  communications  at  a tele- 
processing system  level  as  opposed  to  dealing  separately  at  the  com- 
puter and  communication  levels.  Guidance  was  requested  for  the 
management,  development,  modification,  and  maintenance  of  tele- 
processing systems  to  achieve  potential  improvements.  Six  major 
areas  influencing  teleprocessing  were  identified  for  consideration 
(Appendix  A). 

ADP-related  assets  may  be  interconnected  through  a communications 
network  (teleprocessing)  to  achieve  new  or  augmented  capabilities.  The 
internetting  of  these  assets  provides  a means  of  defining  the  benefits 
and  management  issues.  As  with  the  presently  existing  ADP  systems 
there  is  not  as  yet  and  probably  will  not  soon  exist  a unique  set  of 
management  guidelines  or  quantitative  ordering  of  benefits  of  various 
alternatives  for  managing  the  development  of  teleprocessing  systems. 

The  ADP  technology  is  in  a high  state  of  flux  (as  usual)  with  an  excep- 
tionally dynamic  and  diverse  market  for  application  ranging  from  major 
system  upgrades  (e.g.,  adding  remote  terminals  to  established  computer 
centers),  to  new  capabilities  to  support  established  missions  (e.g., 
interactive  inquiry /response  for  real-time  systems--operations  sched- 
uling, logistics,  command  and  control,  etc.)  and  potentially  new 


This  office  has  been  redesignated  as  Director,  Telecommunications 
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systems  creating  new  activities  or  heavily  influencing  current  activ- 
ities (e.g.,  distributed  processing,  personal  processing,  cashless 
society,  etc.). 

It  was  recognized  early  in  the  study  that  the  subject  of  tele- 
processing is  exceptionally  broad  and  complex  with  many  faceted  inter- 
actions and  possible  interfaces  among  suppliers,  purchasers,  and  users 
within  DoD  and,  even  more  generally,  within  the  commercial  world  as  a 
whole.  With  the  limited  resources  available  it  was  decided  to  focus 
primarily  on  the  network  issues.  The  approach  taken  was  to  consider 
the  problems--technical,  functional,  ar.d  economic--associated  with 
interconnecting  computers  and  terminals  through  one  or  more  communi- 
cations networks  (internetting).  With  the  exception  of  data  security 
and  more  generally  "privacy,”  the  other  areas  of  consideration  may 
then  be  derived  from  this  point  of  view.  The  data  privacy  issue, 
although  not  derivative,  is  tightly  coupled  to  the  networking  issue 
being  bounded  by  access  control  and  computer  compartmentation. 

Given  the  highly  dynamic  (and  competitive)  ADP  technology  and 
applications,  the  common  teleprocessing  ingredient  appears  to  be  the 
network  or  configuration  with  which  ADP  elements  and  their  users  are 
arranged  over  distance  and  through  time.  Categorization  and  charac- 
terization of  candidate  classes  of  networks  and  their  management  im- 
plications to  DoD  became  the  primary  objectives  of  the  effort  under- 
taken. 

Most  off-the-shelf  teleprocessing  systems  currently  available 
are  oriented  toward  a user-dedicated  (usually  owner)  system  of  highly 
"integrated"  network  components  consisting  of  (one  or  very  few)  com- 
puter sites  connected  to  dedicated  communications  transmission  lines 
and  terminals.  For  each  such  dedicated  system,  management  is  system 
specific  to  the  ADP /communications  facility  (i.e.,  teleprocessing 
system).  Any  sufficiently  large  corporate  entity,  and  specifically 
DoD,  will  experience  a demand  for  a multiplicity  of  diverse  ADP  serv- 
ices, each  of  which  could,  and  in  some  cases  may  have  to,  be  satisfied 
by  dedicated  teleprocessing  systems.  Consequently,  higher  level 


management  issues  will  develop  with  regard  to  shared  versus  dedicated 
facilities.  In  this  regard,  emphasis  is  given  to  aggregation  of  re- 
quirements, users,  assets,  and  function  as  differentiated  from  specific 
systems  design  and  operation.  The  current  ADP  technological  and  mar- 
keting environment  is  oriented  toward  supporting  individual  dedicated 
svstems  and  as  such  would  tend  to  proliferate  networks  and  systems. 

To  the  extent  that  such  proliferation  is  costly  (or  nonrevenue  pro- 
ducing) teleprocessing  management  issues  will  have  to  focus  on  con- 
trolling or  reducing  proliferation  through  aggregation  and  sharing. 

In  the  current  ADP  context,  management  contends  with  a multiplic- 
ity of  dedicated  teleprocessing  systems.  Another  alternative  is  emerg- 
ing through  the  development  of  common-user  switched  data  networks*  in 
which  computer  sites  and  remote  terminals  are  subscribers  to  a common- 
user  data  communications  (sub)network.  In  this  regard,  the  computers 
and  terminals  are  differentiated  from  the  communications.  For  this 
case  the  systems  management  function  is  considerably  changed  inasmuch 
as  the  data  communications  subnet  is  under  separate  management  from 
the  ADP  and  terminal  sites.  At  the  corporate  level,  common-user  fa- 
cilities become  another  option  to  be  considered  for  implementing  tele- 
processing functions  and  sharing  resources. 

From  the  foregoing  it  should  be  evident  that  teleprocessing 
management  issues  require  clarification  and  policies  need  to  be  de- 
veloped. The  purpose  of  this  study  was  to  identify,  address,  and 
categorize  these  issues  as  they  apply  to  the  DoD. 


This  approach  has  been  given  consi ierable  support  by  DARPA  with  the 
development  of  the  ARPANET.  Three  commercial  firms  (PCI,  TELENET, 
and  GRAPHNET)  have  been  granted  FCC  approval  to  implement  and  tariff 
such  common-user  data  communications  while  a time-sharing  service 
company,  TYMNET,  is  already  utilizing  a portion  (~  25%)  of  its  com- 
munications capacity  to  provide  common-user  switched  data  communi- 
cations. These  companies  use  the  basic  transmission  facilities  of 
the  Common  Carriers  and  add  their  own  data  switching  and  multiplexing 
facilities  for  sharing  capacity.  Consequently,  they  are  referred  to 
as  Value  Added  Networks  (VANs). 
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B.  APPROACH 

The  objective  of  this  study  was  to  examine  teleprocessing  network 
design,  configuration,  and  capabilities  as  they  relate  to  DoD  needs. 
This  was  done  by  area  of  application,  by  design  alternatives  and  tech- 
nology, and  by  development  needs.  This  then  leads  to  formulating 
policy  issues  and  alternatives.  A major  difficulty  has  been  the 
strong  interaction  between  requirements,  use,  design,  and  ownership 
of  teleprocessing  systems.  No  accepted,  "natural,"  or  "right"  decom- 
position and  ordering  of  the  problems  have  as  yet  emerged.  The  decom- 
position and  structuring  of  teleprocessing  system  applications  used 
here  represent  a framework  the  authors  felt  to  be  meaningful  and  to 
serve  the  purpose  of  being  a point  of  departure  for  exhibiting  the 


issues . 


In  this  study  teleprocessing  applications  are  grouped  into  the 


following: 


Type  I:  Command  and  Control 


General  Nuclear  War 


Dominant 

Attributes 


Survivability 


b.  C-5  Crisis  and  Contingency  Peak  Demand 


Type  II:  General  Service  Applications 


Economic  Use  of 
ADP  Functions 


Excluded  from  consideration  were  the  teleprocessing  applications 
dealing  with  or  integral  to; 

• Weapon  Systems 

• Tactical  C^ 

• Intelligence 

The  weapon  systems  and  tactical  C3  applications  were  beyond  the  scope 
of  this  effort.  Due  to  the  limitations  of  time  and  effort  and  con- 
sidering the  special  access  features  associated  with  intelligence  sys- 
tems, this  application  area  also  was  not  addressed.  A major  policy 
issue  for  near-term  consideration  is  the  interaction  between  and 


degree  of  facility  sharing  (terminals,  communication,  computers) 
among  special  and  conventional  teleprocessing  networks. 

The  principal  approach  was  used  to  survey  and  review  technology, 
design,  modeling,  requirements,  in  general,  and  proposed  DoD  teleproc- 
essing systems.  From  this  effort,  major  issues  and  possible  future 
directions  were  elicited  and  placed  in  relation  to  DoD  alternatives. 

As  discussed  in  Section  V,  detailed  design  analysis  depends  heavily  on 
modeling  and  simulation  requiring  (1)  significant  data  bases,  (2)  pro- 
grammed models,  and  (3)  iterative  heuristic  solution  techniques.  In 
all  of  the  cases  reviewed,  the  analysis  and  results  tended  to  be  quite 
specific  requiring  significant  computational  effort.  Since  a broad" 
view  of  the  problem  area  was  the  principal  objective  of  this  study,  no 
attempt  was  made  to  develop  a mathematical  analysis.  A review  of  the 
"state  of  knowledge"  in  analyzing  teleprocessing  systems  is  presented 
in  Section  V.  To  date,  no  broad  theory  of  teleprocessing  has  developed 
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III.  TELEPROCESSING  APPLICATIONS 

A.  APPLICATION  TYPES 

In  order  to  provide  some  framework  within  which  teleprocessing 
networks  could  be  judged,  this  study  chose  to  categorize  networks 
by  utilization  of  attributes  along  classes  of  application  in  the  DoD. 
Two  major  application  areas  identified  and  examined  are  listed  below: 

• Type  la  - Command  and  Control  of  the  Nuclear  Forces 

lb  - Nonnuclear  Crisis  and  Contingency  Command 
and  Control 

• Type  II  - General  ADP  Services  Applications 

Although  excluded  from  consideration,  the  tactical  and  intelligence 
applications  clearly  must  interface  and  selectively  share  resources 
with  networks  supporting  the  above. 

The  purpose  of  categorizing  teleprocessing  needs  by  application 
area  type  is  to  focus  the  discussion  on  key  system  parameters.  These 
parameters  need  not  receive  the  same  emphasis  nor  even  need  be  com- 
patible (e.g.,  survivability  capacity,  speed  of  service,  geographic 
coverage,  cost-effective  throughput,  etc.)  between  application  types. 
The  area  types  identified  appear  to  have  consistent  parameters  of 
design  emphasis.  These  area  types  associate  with  a relationship  be- 
tween C3  systems,  the  military  forces,  the  military  departments,  and 
agencies  of  the  DoD  as  shown  in  Fig.  1. 

Type  I applications  are  centered  on  NCA  support  with  heavy  WWMCCS 
involvement.  Although  each  of  the  Type  la  and  lb  functional  areas  may 
require  support  from  systems  designed  with  dedicated  facilities,  they 
should  be  strongly  coordinated  ("interoperable” ) between  each  other. 
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Type  II  needs,  on  the  other  hand,  are  very  diversified  with  many  points 
of  focus.  There  can  be  expected  to  be  many  subcategories  which  will 
be  discussed  further  in  the  report. 


FIGURE  1 . Categories  of  Teleprocessing  Applications  in  DoD 


Given  a categorization  of  DoD  teleprocessing  needs,  several  ques- 
tions as  to  implementation  can  be  raised. 

• Can  some  or  all  of  Type  la  needs  be  met  in  a satisfactory 
manner  by  components  of  networks  satisfying  Type  II  needs? 

• Alternatively,  given  a dedicated  network  to  support  Type  la 
requirements , could  it  also  support  in  part  some  Type  lb 

or  even  Type  II  needs? 

• What  are  the  balance  and  interfaces  between  a dedicated 
Type  lb  network  and  preempts  of  Type  II  network  capacities? 

• What  is  the  network  relation  between  Type  lb  and  Type  II? 

The  Type  I and  II  categorization  chosen  was  based  on  aggregating 
apparently  consistent  needs  which  dictate  design  requirements. 
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Developing  such  requirements  in  technical  terms  will  then  provide  a 
means  for  judgment  of  network  implementation. 

Several  broad  network  functional  characterizations  suggest  them- 
selves. The  following  lists  some  of  these: 

1.  Degree  of  System  Homogeneity /Heterogeneity  between 

• Users 

• Hardware 

• Software 

2.  Connectivity  and  Data  Exchange  Demands 

• User  density 

• Geographic  coverage 

• Availability 

3.  Type  of  Service 

• Batch /remote  job  entry 

• Transactional/inquiry  response 

4.  Capacity  Needs 

• Average  throughput 

• Speed  of  service 

• Load  peaking 

5.  Special  Features 

• Survivability 

• Priority/preempt 

• Multilevel  security 

In  the  remainder  of  this  section,  these  functional  factors  will  be 
discussed  relative  to  the  application  area  types. 

It  was  felt  that  within  the  present  understanding  of  the  WWKCCS 
organization  and  assigned  areas  of  responsibility  within  the  Services, 
the  categorization  chosen  is  at  least  a useful  point  of  departure. 
Moreover,  there  have  been  systems  proposed  which  match  (i.e.,  sug- 
gested) this  categorization.  For  concreteness,  these  systems  are 
used  as  examples  in  the  discussion  to  follow.  There  is  not  a clear 
demarcation  between  systems’  function  and  use.  Very  important  archi- 
tectural issues  are  yet  to  be  determined.  For  real-time  interactions 
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Type  la  need  not  be  required  to  interact  as  closely  with  Type  II  ap- 
plications as  it  would  with  Type  lb  applications.  On  the  other  hand, 
Type  lb  and  some  Type  II  systems  could  require  close  real-time  inter- 
action during  crisis/contingency  periods.  The  view  could  be  taken 
that  a Type  lb  system  serves  as  an  interface  between  Type  la  and  Type 
II  systems.  Status  data  collected  in  a Type  II  system  could  be  for- 
warded periodically  through  a Type  lb  system  which  interacts  with 
Type  la. 

For  the  purposes  of  discussion,  Types  la  and  lb  are  here  separated 
in  order  to  emphasize  those  functional  attributes,  survivability  and 
peaking  capacity  demand,  which  can  and  will  strongly  influence  and 
differentiate  network  design  parameters.  After  discussing  such  sys- 
tems separately,  the  issues  of  implementing  interfaced  but  separate 
(sub)systems  into  an  integrated  system  can  be  addressed. 

The  above  discussion' also  applies  to  separating  Type  I systems 
from  Type  II  systems.  It  is  postulated  that  a considerable  functional 
difference  exists  between  Type  la  and  Type  II  applications.  Since 
Type  la  applications  relate  to  the  U.S.  nuclear  capability,  and  to 
the  extent  that  these  requirements  dictate  Type  la  system  design,  a 
separation  of  Type  la  from  Type  II  applications  is  justified.  It 
should  be  noted  that  in  most  peacetime  modes  (i.e,,  excluding  test 
and  training)  a Type  la  system  may  be  used  for  some  Type  II  applica- 
tions (but  possibly  at  limited  capacity  and/or  in  a less  cost-effective 
manner) . 

In  summary,  for  the  purposes  of  relating  teleprocessing  functional 
needs  to  design,  three  application  areas  are  stipulated.  The  need  for 
interaction  between  Types  la  and  lb  as  well  as  between  Type  lb  and 
certain  Type  II  systems  is  clear.  The  need  for  real-time  interaction 
between  Type  la  and  Type  II  is  less  obvious.  The  network  functional 
designs  will  be  outlined  by  type  and  compared. 

B.  TYPE  I NEEDS 

This  section  addresses  Type  I teleprocessing  needs  which  are 
WWMCCS  driven.  Type  I system  needs  are  subdivided  principally  by  the 


nature  of  their  teleprocessing  design  emphasis.  Type  la  must  emphasize 
survivable  connectivity  to  specified  units  through  the  transattack 
period  to  pass  a minimal  volume  of  essential  command  data  reports. 

Type  lb,  on  the  other  hand,  must  function  with  periods  of  large  data 
capacity  peaks  without  a priori  knowledge  of  where  and  when  such  capac- 
ity will  be  needed  nor  the  specific  nature  of  the  data.  In  addition, 
Type  lb  systems  need  not  be  tasked  to  survive  as  high  a nuclear  threat 
level  as  that  facing  Type  la  systems. 

1.  Type  la  Systems — Command  and  Control  Nuclear  Forces 

a.  SATIN  IV  Synopsis.  The  SAC- proposed  SATIN  IV  system  fits 
within  the  Type  la  characterization  as  described  in  Ref.  6.  The  pur- 
pose of  the  SATIN  IV  system  will  be  to  provide  an  interactive  data  com- 
munications system  by  the  late  1970s  which  would  support  command  and 
control  of  SAC’s  general  war  forces  and  maintain  connectivity  with  the 
NCA.  It  is  to  be  an  integral  part  of  the  WWMCCS  under  operational  con- 
trol of  CINCSAC.  The  objectives  of  SATIN  IV  are  to  transmit  critical 
command  and  control  information  including: 

(1)  Command  and  orders,  EAM  (emergency  action  message) 
and  essential  operational  data 

(2)  Force  management  data 

(3)  Situation  data 

(4)  Intelligence  and  force  status  data 

( 5 ) Weather  data 

(6)  Other  messages  as  necessary. 

SATIN  IV  will  have  two  modes.  Mode  1 is  primarily  a ground-based 
transmission  system;  for  enhanced  transattack  survivability,  Mode  2 
utilizes  satellite  (AFSATCOM)  and  air-to-air  relay  (PACCS)  radio  trans- 
mission at  reduced  transmission  capacity.  SATIN  IV  is  also  required 
to  operate  with  the  MEECN,  EMATS,  and  AUTODIN  communication  systems. 

The  SATIN  IV  system  is  planned  to  interface  to  the  NCA  at  the  NMCS 
command  posts  (NMCC,  ANMCC,  and  NEACP). 

The  SATIN  IV  Mode  1 system  is  primarily  a fast  store  and  forward 
message  switching  network  utilizing  packet  switching  technology  with 
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AUTOVON  transmission  facilities.  This  system  is  a distributed  ground- 
based  network  interconnecting  advanced  data  terminals  at  SAC  units  with 
computers  (including  a WWMCCS  computer)  at  SAC  Headquarters,  Omaha,  and 
the  WWMCCS  computer  at  the  ANMCC  at  Ft.  Ritchie.  There  are  many  sites 
with  user  terminal  equipment  (UTE)  but  only  two  host  computer  sites. 

The  proposed  network  layout  is  shown  in  Fig.  2.  This  network  utilizes 
transmission  lines  derived  from  the  AUTOVON  system  with  packet-type 
minicomputer  switches  (Regional  Communications  Processor--RCP)  and  con- 
centrators (Base  Communications  Processor--BCP) . The  RCP  switches  are 
multiply  connected  to  at  least  three  other  RCPs  through  AUTOVON  for  en- 
hanced survivability  through  switch  routing.  The  transmission  speeds 
vary  up  to  9.6  kbps.  The  writer- to-reader  system- response-time  objec- 
tive for  highest  precedent  messages  is  no  more  than  10  sec.  The  trans- 
mission lines  are  derived  by  establishing  AUTOVON  calls  at  the  Flash 
Precedence  level  with  the  intent  to  keep  the  called-up  circuit  in  con- 
tinuous full-duplex  use.  Should  a line  fail  or  be  preemped  (Flash 
Override),  the  RCP  is  to  have  an  Autodial  capability  to  call  up  another 
AUTOVON  line. 


2-12-75-7 

FIGURE  2.  Proposed  SATIN  IV  Network  (Ref.  6) 
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b.  Discussion  of  Type  la  Applications.  As  can  be  seen  from  the 
above  synopsis,  SATIN  IV  would  be  a backbone  switched  data  transmission 
system  within  SAC  and  in  support  of  the  NCA.  The  management  emphasis 
of  the  program  is  on  data  communications , yet  examination  of  the  sys- 
tem exhibits  a strong  dependence  on  teleprocessing  design  principles. 

SATIN  IV  represents  a major  component  of  the  Type  la  applications 
but  does  not  cover  all  the  needs.  Mode  1 capability  does  not  extend 
beyond  SAC  forces.  To  the  extent  that  the  other  nuclear  capable  forces 
acquire  AFSATCOM  assets,  Mode  2 operation  can  extend  SATIN  IV  coverage 
beyond  SAC  forces.  A single  integrated  Type  la  teleprocessing  system 
has  yet  to  be  proposed.  Interfaces  between  other  CINCs  and  the  NCA 
can  evolve  using  the  WWMCCS  framework  and  MEECN,  JCSAN,  EMATS,  AUTOVON, 
AUTODIN,  SATCOM,  etc.,  assets  plus  possibly  extending  the  SATIN  IV  sys- 
tem or  developing  additional  systems. 

SATIN  IV  Mode  1 utilizes  a subscriber-oriented  packet- switching 
technology  which  also  has  potential  for  application  to  other  switched 
data  networks.  However,  SATIN  IV  would  service  a relatively  homogeneous 
set  of  equipments  and  utilization  factors  (data  formats,  elements,  ex- 
change requirements).  There  are  currently  to  be  a very  limited  number 
of  host  computer  locations  in  the  system  with  relatively  well-structured 
application  requirements  associated  with  the  structured  approach  to 
command  and  control  of  the  SAC  nuclear  forces . 

SATIN  IV  will  have  to  solve  certain  unique  problems  such  as: 

• Autodial  capability  on  AUTOVON 

• Air/ground  radio  links  with  AABNCP 

• A variety  of  site-dependent  interfacing  problems  such  as 
SAC  host  computer  complex  and  MINUTEMAN  launch  control 
facilities . 

Mode  2 will  have  additional  and  possibly  more  severe  interfacing  prob- 
lems induced  by  AFSATCOM  reduced  capacity  and  unique  signalling  format. 

The  SATIN  IV  system  will  be  required  to  pass  information  classi- 
fied through  SI  and  ESI  levels.  The  data  security  approach  presently 
being  taken  is  to  secure  the  AUTOVON  transmission  lines  to  the  appro- 
priate level  with  conventional  ComSec  equipment.  The  switches  and 
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terminals  are  to  be  physically  located  in  secure  areas.  Several 
problems  generic  to  multilevel  security  in  all  teleprocessing  systems 
must  be  addressed.  First,  the  switches  and  terminals  must  be  guar- 
anteed to  some  level  of  probability  not  to  violate  security  through 
failure  modes,  mis programming , or  deliberate  penetration  attempts. 

For  example,  a sensitive  data  element  should  not  be  misrouted  to  an 
uncleared  area.  Second,  the  terminal  and  computer  will  have  to  be 
secured  in  validating  the  terminal’s  ’’user”  (usually  human  but  possi- 
bly another  machine)  right  to  interact  with  the  information  at  a given 
level  and  protection  against  misuse  or  failure.  When  the  terminal  is 
in  a secure  area,  the  principal  burden  is  placed  upon  the  host  computer. 
The  computer  must  check  user  ID  (identification)  and  validate  his  cre- 
dentials. Then  the  computer  needs  to  generate  internal  barriers  to 
deny  the  user  access  to  data  and  programs  beyond  his  "access  rights." 
This  latter  function  is  essential  and  short  of  physically  separating 
computers;  no  fully  satisfactory  approach  to  solving  this  problem  is 
known  for  time-sharing  multiuser  computing  systems. 

The  problem  of  interfacing  Type  la  systems  to  other  DoD  tele- 
processing networks  remains.  In  Ref.  7 consideration  was  given  to 
some  of  the  technical  problems  in  data  structure  and  security  for  in- 
terconnecting SATIN  IV  to  AUTODIN  II  (Ref.  1).  There  still  remain 
unaddressed  problems  relating  to  control,  precedence,  and  usage  fac- 
tors. These  problems  are  further  described  in  Section  VII-E. 

c.  Summary  Type  la  Systems.  It  can  be  expected  that  the  fol- 
lowing features  are  generic  to  Type  la  teleprocessing  systems: 

• Structured  nature  of  ADP  work  load  as  determined  by 
nuclear  war  planning 

• Relative  homogeneity  of  users  and  their  individual 
equipment 

• High  emphasis  on  survivable  connectivity  through  transattack 

• Site-unique  features  of  nuclear  forces  and  command  centers. 

Design  features  which  decrease  available  and  survivable  system 
capacity  may  not  be  tolerable.  For  example,  intermittent  system 


blockage  or  delays  caused  by  an  inadequately  controlled  set  of  user 
access  during  a period  of  peak  demand  could  be  very  deleterious.  In- 
creased cost- per-unit  throughput  added  by  survivability  features  may 
be  tolerable  for  Type  la  users  but  not  others.  Performance  measures 
of  Type  la  systems  should  be  heavily  oriented  toward  maximizing  proba- 
bility of  timely  delivery  of  essential  messages  between  command  and 
forces  in  the  face  of  maximum  threat  levels.  This  contrasts  to  eco- 
nomic-oriented  measures  for  Type  II  systems  which  would  focus  on  cost- 
effective  performance  such  as  minimum-cost-per-system  transaction. * 

2 . Type  lb  Systems--Crisis  and  Contingency  Command  and  Control 

a.  WWMCCS  Teleprocessing  Objectives.  Type  lb  application  areas 
relate  to  WWMCCS  support  of  the  NCA  for  command  and  control  capabili- 
ties of  U.S.  forces  through  Crisis  and  Contingency  operations.  One 
means  for  enhancing  this  capability  is  the  proposal  to  interconnect 
and  thereby  interoperate  with  selected  WWMCCS  ADP  sites.  At  present, 
the  Joint  Technical  Support  Activity  (JTSA)**  is  conducting  an  experi- 
ment, the  Prototype  WWMCCS  Intercomputer  Network  (FWIN),  to  inter- 
operate three  WWMCCS  computers,  one  each  at  the  following  sites;  JTSA/ 
Reston,  Va.,  NMCSSC /Pent agon,  and  CINCLANT/Norf oik , Va.  Several  pro- 
posals have  been  advanced  to  enlarge  the  number  of  WWMCCS  ADP  sites 
to  be  interconnected.  One  is  to  expand  the  experimental  PWIN  (Ex- 
panded PWIN);  another  is  to  establish  a separate  operational  WWMCCS 
Internet  (WIN)  (Ref.  8),  or  utilize  at  some  future  date  the  DCA-pro- 
posed  AUTODIN  II  (IDN)  common-user  switched  data  network. 


rc 

This  is  one  of  many  of  the  Type  II  economic  performance  measures . 
Another  might  be  maximum  operating  dollars  saved  per  dollar  tele- 
processing invested.  The  principal  point  is  that  Type  la  has  radi- 
cally different  basis  for  design  and  economic  justification. 

JTSA,  under  the  cognizance  of  the  Director,  DCA,  serves  as  the  WWMCCS 
ADP  System  Manager  responsible  to  the  JCS. 
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The  broad  ADP  objectives  of  a WWMCCS  Internet  in  ascending  order 
of  difficulty  will  be  to: 

1.  Provide  overall  continuity  of  ADP  operations  through 
individual  computer  failures. 

2.  Utilize  geographically  distributed  data  bases  in  order 
to  (a)  maintain  more  current  file  data,  (b)  reduce  the 
volume,  time,  and  cost  of  daily  file  transfers,  and 
(c)  minimize  duplication  of  data  bases  and  their  sup- 
port costs. 

3.  Acquire  an  advanced,  distributed,  interactive,  and 
transactional  system  capability  to  support  quick  re- 
action contingency  planning  for  command  and  control 
of  the  U.S.  forces. 

b.  WWMCCS  Data  Flow.  In  May  1972,  a study  (Ref.  9)  was  published 
projecting  WWMCCS  intercomputer  traffic  flow  for  the  late  1970s.  This 
study  was  conducted  for  JTSA  by  Mitre  Corporation,  The  data  were  com- 
piled through  extensive  interviewing  of  WWMCCS  ADP  site  personnel. 

This  study  is  useful  for  the  manner  in  which  the  data  transactions 
were  organized  and  in  estimating  projected  traffic  flow.*  This  struc- 
ture is  repeated  here  in  summary  form.  The  WWMCCS  element  relation- 
ships used  by  the  Mitre  study  are  shown  in  Fig.  3 showing  NMCS,  CINC 
and  CINC  components  in  the  VMMCCS.  The  data  to  be  exchanged  were  put 
into  six  operational  groupings.  Associated  with  each  are  the  indicated 
reporting  systems  (for  summaries  of  these  reporting  systems,  see  Ref.  9). 


These  values  for  initial  planning  estimates  were  derived  prior 
to  experience  with  PWIN,  subsequent  WWMCCS  ADP  developments,  and 
OSD  guidance. 
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FIGURE  3.  WWMCCS  Element  Relationships  (Ref.  9) 


Operational  Grouping  Data  File  and  Reporting  Systems 


1. 

Status  of  Forces 

FORSTAT,  MOVREP,  PACREP 

2. 

Logistics 

PACSHIPS , MUNIREP,  POLREP, 

WAR  RESERVES 

3. 

Force  Deployment 

DEPREP 

4. 

Reconnaissance  and  Intelligence 

PATF,  RIS,  IDHS 

5. 

Limited  War* 

FRDMA , OPREP,  SITREP, 
SPECIAL  SEA,  COACT,  ALOREP 

6. 

General  War 

CAOSOP,  NUCINV , and  under 
General  War  conditions , 

OPREP,  SITREP,  COACT , DISUM, 
SPIREP,  INTSUM,  NUDET,  NUSUM, 
COMSTAT,  COMSPOT,  PERSTAT, 
REPOL,  MUNIREP,  REDSEAL, 
POLREP,  CRAFREP. 

Each  of  the  six  operational  groupings  was  then  examined  by  Mitre 
in  Ref.  9 for  three  situations;  Normal,  Crisis,  and  General  War.  The 
traffic  flow,  with  the  exception  of  groups  3,  4,  6 above,  is  princi- 
pally upward  in  the  command  chain  with  medium- to- large  daily  volumes 
(with  a distributed  data  base  system,  the  traffic  flow  might  be  re- 
duced). The  data  flow  concept  used  for  FORSTAT  is  shown  in  Fig.  4 but 
is  equally  applicable  to  Logistics  and  Limited  War.  Force  Deployment 
(3)  is  expected  to  have  infrequent  lateral  flow  exchanges.  Reconnais- 
sance and  Intelligence  (4)  is  expected  to  have  large  daily  flow  dis- 
tributed throughout  the  system.  General  War**  (6)  is  expected  to  have 
"large  flow"  distributed  throughout  with  "critical  survivability  and 
timeliness  requirements." 



* 

Some  of  these  were  Southeast  Asia  specific  and  may  have  since  been 
modified  or  phased  out. 

ic’k 

The  Mitre  study  also  covers  Type  la  applications  and  serves  to 
highlight  some  of  the  overlap  and  interface  needs.  The  General 
War  Reporting  Systems  listed  above  are  extensive  and  may  not  be 
completely  supportable  through  a transattack  phase  with  current 
and  projected  Type  la  systems. 
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FIGURE  4.  Example  FORSTAT  Strategy  (Ref.  9) 
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c.  PWIN  and  WIN  Synopsis.  The  WIN  system  proposed  in  Ref.  8 
is  a packet-switching  data  transmission  system  which  would  connect 
eight  WWMCCS  sites  (plus  the  JTSA/Reston  site)  as  shown  in  Fig.  5 
(JTSA/Reston  inadvertently  omitted).  An  alternative  approach  to  WIN, 
currently  being  given  serious  attention,  is  to  expand  the  current 
PWIN  configuration  to  several  more  sites  (tentatively  REDCOM,  ANMCC, 
and  MAC)  using  PWIN  components  and  software.  This  would  still  be 
developmental  but  would  allow  experimenting  in  a more  operational- 
type  environment  without  making  long-term  technical  or  cost  comitments. 
The  principal  thrust  for  development  and  utilization  of  such  effort 
would  be  in  the  direction  of  supporting  crisis /contingency  command 

and  control. 

d.  Discussion  of  Type  lb  Systems.  From  the  above  it  can  be  seen 
that  an  initial  effort  within  the  WWMCCS  ADP  community  is  being  made 
to  experiment  with  Type  lb  applications.  The  need  for  an  interface 
with  Type  la  applications  is  recognized  but  not  as  yet  fully  under- 
stood. At  present  the  Type  lb,  crisis /contingency,  ADP  support  deals 
with  large,  relatively  static,  files  collected  through  reporting  sys- 
tems with  distributed  collection  responsibility.  Emphasis,  therefore, 
will  fall  on  the  problems  of  data  base  structure,  utilization  proto- 
col, and  multiuser  interaction. 

The  Type  lb  teleprocessing  applications  area  would  appear  to  be 
characterized  by  homogeneous  hardware  at  the  WWMCCS  site  (i.e.,  WWMCCS 
standard  computers)  but  heterogeneous  missions  and  tasks  which  generate 
varying 

• Site  hardware  configurations  (memories,  terminals,  etc.) 
including  interfaces  to  nonstandard  WWMCCS  ADP  equipment 

• Applications  programs  and  their  data  elements 

• Allocation  and  scheduling  of  ADP  assets 

• Personnel  training  and  experience. 

In  this  regard,  Type  lb  applications  are  more  varied  than  Type  la 
but  still  retain  some  hardware  homogeneity  (as  compared  to  Type  II) 
through  the  standard  WWMCCS  ADP  computers.  In  further  contrast  to 
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FIGURE  5.  WWMCCS  Intercomputer  Network  Proposed  in  Ref. 
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Type  la,  Type  lb  need  not  require  as  high  a level  of  survivability 
against  nuclear  threats.  Consequently,  more  economical  performance 
should  be  expected.  However,  many  unique  features  will  be  required 
such  as; 

• Unpredictable  peaking  demand  on  potentially  any  system 
assets  depending  on  the  nature,  location,  duration,  etc., 
of  the  crisis  or  contingency;  thus  emphasizing  flexible 
preempt  capability  while  minimizing  disruption  to  unaf- 
fected functions. 

• Ability  to  interface,  interconnect,  interoperate  (as  appro- 
priate) with  selected  system  extending  downward  from 

the  CINC  level  to  the  tactical  forces  on  an  itinerant  basis. 

• Rapid  and  flexible  development  of  system  configuration  and 
application  programs  to  unique  features  of  contingency 
activities . 

• A distributed  as  well  as  complex  set  of  "compartments" 
and  "accessibility"  for  multilevel  security  requirements. 

• Ability  to  verify,  associate,  correlate,  and  update  multiple 
reports  from  differing  systems  generated  by  a common  set 

of  events. 

I In  addition  to  hardware  and  system  interface  problems  that  will 

have  to  be  addressed,  it  can  be  expected  that  significant  advances 
[ in  the  science  of  data  processing  techniques  will  be  needed. 

C.  TYPE  II  GENERAL  APPLICATIONS 
1.  Introduction 

| A major  dif ferentiation  used  here  between  Type  I and  Type  II 

applications  is  in  the  emphasis  on  command  and  control  capabilities 
i versus  economic  factors  (e.g.,  productivity  and  cost).  In  this  report, 

Type  II  applications  in  the  DoD  are  analogous  to  civilian  commercial 
applications  of  teleprocessing  such  as  Management  Information  Systems, 
Time-Sharing  Systems,  Remote  Service  Bureaus,  Reservation  and  Scheduling 
Systems,  and  so  forth.  DoD  in  its  support  activities  can  be  viewed  as 
[ a large  corporation  (or  more  likely  "conglomerate" ) composed  of  many 

semi-autonomous  divisions  which  are  responsible  to  the  Corporate  Head- 
quarters (i.e.,  OSD).  As  such,  teleprocessing  systems  are  proposed, 
acquired,  and  used  by  the  various  Corporate  Division  elements  in  order 
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to  support  their  daily  operations,  increase  productivity,  and  reduce 
costs  (usually  personnel).  The  problem  of  managing  Type  II  systems 
in  DoD  is  similar  to  a commercial  corporation  except  that  the  problems 
are  amplified  by  the  extensive  geographical  distribution  of  activities 
and  very  large  size  of  the  DoD.*  One  of  the  principal  concerns  of 
this  report  relates  to  identifying  problems  and  structuring  policy  and 
strategy  alternatives  for  managing  "Corporate"  use  of  teleprocessing. 

Within  DoD,  Type  II  teleprocessing  applications  can  be  aggregated 
in  many  different  subtypes.  This  variability  in  possible  aggregations 
is  in  of  itself  a major  problem.  No  a priori  "natural,"  good,  or  at- 
tractive aggregation  of  teleprocessing  applications  has  yet  to  suggest 
itself.  In  this  section  several  alternative  classes  of  teleprocessing 
applications  will  be  discussed  in  Sections  3 through  5. 

2 . Discussion  of  Type  II  Applications 

a.  Systems  and  Organizations.  There  is  a very  large  variability 
in  Type  II  applications.  However,  one  common  factor  is  the  emphasis 
placed  on  economical  delivery  of  ADP  goods  and  service  with  less 
stringent  requirements  on  survivability  or  timeliness  as  there  is 
with  Type  I systems.  Type  II  applications  may  vary  from  homogeneous 
systems  to  very  heterogeneous  ones.  The  level  of  difficulty  in  the 
design  and  operational  utilization  problems  of  a Type  II  system  can 
be  expected  to  be  higher  with  greater  heterogeneity  of  hardware, 
software,  and  community  of  users. 

Requirements  Formulation  (Section  IV)  and  user/system  organiza- 
tion will  be  a major  issue  for  Type  II  Teleprocessing  Applications. 

A variety  of  Type  II  categorizations  (or  hierarchies  of  categoriza- 
tion) are  possible.  Several  methods  of  aggregation  suggest  them- 
selves as  follows; 


In  this  regard,  although  DoD  is  a very  large  "Corporation"  indeed, 
it  still  represents  a small  fraction  of  the  aggregated  total  busi- 
ness consumption  of  ADP  goods  and  services. 


• By  organization  of  an  associated  user  community  such  as 
components  of  military  departments  or  agencies,  command 
activities,  mission  activities. 

• By  geographical  regions. 

• By  similarity  of  applications  systems  such  as  logistics  and 
supply,  operations  scheduling,  status  reporting,  personnel, 
finance. 

• By  the  technical  characteristics  of  the  ADP  and  communi- 
cations load  and  service  such  as  batch  processing, 
centralized  bureau  ADP  support,  remote  job  entry,  trans- 
actional or  inquiry/response,  circuit  or  packet  switching, 
common  interface  standards,  etc. 

• By  security  requirements. 

The  above  modes  derive  from  consideration  of  (1)  conventional  organi- 
zational structure,  (2)  geographic  proximity,  (3)  standardization  of 
function,  (4)  type  of  ADP  work  load,  and  (5)  constraints  in  mixing 
sensitive  data.  It  has  not  been  possible  to  discover  a best  mode  for 
aggregating.  Each  has  advantages  and  disadvantages  and,  with  the  pos- 
sible exception  of  aggregation  by  technical  characteristics  and  secu- 
rity, Type  II  systems  have  been  proposed  which  reflect  each  of  the 
first  three  modes.  For  example,  consider  the  following  proposed 
systems : 

• By  organization--MAC  Information  Management  System 

• By  geographical  region--Navy  Data  Processing  Service 
Center  and  Army  Northeast  Computer  Center 

• By  standard*  applications--Joint  Uniform  Military 
Personnel  Systems  (JUMPS) 

The  SADPR-85  Computer  Network  concept  discussed  in  the  following 
represents  a mix  of  the  organization  and  geographic  aggregation  modes 
but  within  a well-defined  and  unique  military  organizational  structure. 
On  the  other  hand,  JUMPS  is  a DoD-wide  standard  system  to  be  imple- 
mented across  the  Services.  A major  issue  is  to  determine  the  mix 


The  strongest  version  of  this  approach  would  be  a DoD-Wide  Standard 
System.  Less  stringent  versions  would  be  a Military  Department- 
Wide  Standard  System. 
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of  aggregation  modes , the  resulting  overlap  and  required  information 
exchange  and  interface  between  different  systems.  Each  approach  has 
advantages  and  drawbacks  some  of  which  are  identified  in  Table  1. 


Table  1 exhibits  modes  by  which  teleprocessing  systems  can  be  organized. 


TABLE  1.  MODES  OF  SYSTEM  AGGREGATION  OF  TELEPROCESSING  SYSTEMS 


Mode  of  System 
Aggregation 

Advantages 

Disadvantages 

By  Organization 

• Close  association  of 
users’  missions  and 
functions. 

• Conventional  identifi- 
cation of  management 
responsibility 

• Matches  current  de- 
velopment practice 

• System  functional  dupli- 
cation 

• System  inefficiencies 
through  lack  of  spe- 
cialization 

• Generate  more  complex 
data,  data  exchanges 
and  reporting 

By  Geographical 
Region 

• Minimizes  communi- 
cation costs 

• Possible  economy  of 
scale 

• Emphasizes  "service" 
bureau  capability  at 
expense  of  specialized 
service 

• May  not  provide  adequate 
on-line  service  for  geo- 
graphically extensive 
operations 

• May  have  adverse  impact 
on  data  security  pro- 
tection 

By  Standard 
Application 

• Standard  reports 

• Economy  of  scale  in 
hardware  and  software 

• Common  training  and 
support 

• May  not  provide  adequate 
support  for  mission- 
oriented  operations. 

By  Technical 
Characteristics 

• Allows  separation  and 
independent  optimiza- 
tion of  grossly  dif- 
fering ADP  processing 
tasks 

• Can  fractionate  ADP  sup- 
port to  end  users 

Special  Consid- 
erations, e.g., 
security/privacy 

• Simplifies  technical 
realization  of  spe- 
cial objectives 

• May  unnecessarily  in- 
hibit system  access 

• Can  escalate  costs 
through  asset  duplication 

b.  ADP  and  Communications.  A second  major  issue  area  paralleling 
the  aggregation  and  organization  of  users  is  the  relationship  between 
computer  facilities  and  communications.  These  underlying  issues  are 
focused  by  the  need  to  determine  a balance  between  dedicated  and 


shared  teleprocessing  systems  on  the  one  hand,  and  the  mix  of  dedi 


cated  data  transmission  circuits  and  common-user  data  networks  on  the 


other  hand 


Economies  of  scale  must  be  considered  but  in  a wider  context 
than  communication  costs  alone.  Issues  of  centralized  versus  decen 
tralized  ADP  support  facilities  or,  more  generally,  the  DoD  ADP  eco 
nomic  structure  together  with  security,  O&M,  special  performance 
requirements,  and  interoperability  must  be  considered.  Elaboration 
on  these  issues  for  Type  II  systems  forms  the  principal  purpose  of 
the  following  sections  of  this  study. 


No  ADP  systems  are  static.  There  is  perhaps  a higher  rate  of 
change  in  ADP,  through  hardware  and  software  modification,  evolutions, 
and  major  new  introductions , than  in  any  other  technically  oriented 
field.  Thus,  of  particular  significance  will  be  the  evolution  through 
time  of  Type  II  applications  and  systems.  Policy  and  management  guide' 
lines  must  be  developed  to  aid  in  the  initiation  growth,  consolidation 
replacement,  and  sharing  between  and  amongst  teleprocessing  systems 
for  Type  II  applications.  There  is  as  yet  no  purely  technical  basis 
from  which  such  guidelines  can  be  meaningfully  derived.  As  ADP  capa- 
bility becomes  more  potent  at  less  cost,  the  possibilities  widen 
rather  than  narrow.  In  all  likelihood  successful  guidelines  will 
have  to  be  derived  by  a coordinated  management  decision  from  major 
OSD  policy  objectives,  organizational  and  institutional  responsibili- 
ties, and  critical  functional  deficiencies. 


3.  Merger  of  Existing  Systems;  A Case  Stud’ 


Prior  to  further  discussion  it  is  illustrative  to  consider  a 
specific  example  of  the  corporate  level  Type  II  teleprocessing  manage 
ment  problem.  A major  U.S.  corporation  with  worldwide  activities 
found  that  within  CONUS  two  of  its  major  operating  divisions,  Sales 


and  Field  Engineering  Service,  had  independently  developed  and  main- 
tained two  separate  and  dedicated  teleprocessing  systems,  each  pos- 
sessing its  own  terminals,  communication  lines,  and  host  computers, 
and  each  organized  in  a conventional  network  of  a central  computer 
supporting  remote  terminals.  Investigation  by  Corporate  Headquarters 
revealed  that  these  systems  were  highly  congruent  in  terminal  distri- 
bution, type,  and  usage,  together  with  similar  host  computers.  In 
fact,  for  the  most  part,  Sales  and  Field  Engineering  shared  the  same 
local  and  regional  office  facilities  with  duplicate  terminals  and 
communication  lines.  The  host  computer  sites  are  located  at  Division 
Headquarters  which,  in  turn,  are  separated  by  only  a few  miles.  Thus, 
terminals  and  communications  were  being  duplicated. 

All  hardware  and  operating  software  for  both  systems  were  pur- 
chased from  a single  supplier.  Moreover,  the  type  of  terminal- to- 
host  data  transactions  were  quite  similar.  Thus,  a merging  of  both 
systems  offered  the  potential  for  considerable  reduction  of  cost  in 
terminals,  communications  lines,  and  potentially  host  computers. 

The  corporate  management  proceeded  with  a partial  merger  while 
maintaining  separately  the  functional  identity  of  each  application 
system.  The  old  terminals  (which  were  due  for  upgrading)  were  re- 
placed with  a reduced  number  of  new  cathode- ray  tube  (CRT)  terminals 
which  are  shared  by  both  Sales  and  Engineering  personnel  at  the  com- 
mon field  office.  The  redundant  communication  access  lines  and 
leased  long-haul  data  trunk  capacity  were  phased  out.  The  separate 


host  computers,  however,  are  retained.  New  terminal  concentrators 
had  to  be  acquired  which  would  direct  a data  call  to  the  desired 
host  computer  (or  its  backup).  A moderate  software  engineering  cost 
was  required  to  implement  the  shared  system.  The  option  remains  to 
merge  the  host  computers  at  some  future  date. 

It  is  important  to  emphasize  several  points  in  the  above  example; 
(1)  the  locations  of  use  were  essentially  identical;  (2)  the  hardware 
and  its  resident  operating  software  are  from  one  supplier  and  were, 
if  not  identical,  certainly  compatible  for  interoperation;  (3)  the 
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original  separate  systems  were  centralized  with  a star  configuration 
and  little  switching;  the  shared  systems  are  still  centralized  with 
essentially  an  overlapping  star  configuration  and  minimal  switching; 

(4)  software  input  was  required  to  implement  the  shared  system; 

(5)  identity  of  functional  service  was  maintained  separately  and 
host  computers  are  not  as  yet  merged*;  and  (6)  the  system  merger  is 
still  under  way  and  operational  experience  is  still  being  developed. 
These  points  serve  as  preliminary  introduction  to  problem  areas  which 
will  be  more  fully  addressed  in  the  remainder  of  this  report. 


Replacement  with  a New  System; 
Level  Computer  Network  Concept 


The  Air  Force  SADPR-85  Base 


a.  Objectives.  A highly  illustrative  example  of  a comprehen- 
sive teleprocessing  system  which  would  utilize  a backbone  switched 
network  is  provided  by  the  SADPR-85  Computer  Network  concept  (Ref.  2) 
developed  at  ESD  with  Mitre  support.  Concerned  with  the  potential 
future  obsolescence  of  the  present,  essentially  stand  alone,  Base 
Level  ADP  assets  together  with  an  expected  expansion  of  Base  Communi- 
cations traffic  load,  the  Department  of  the  Air  Force  tasked  ESD  to 
conduct  a study  to  satisfy  a 1985  projected  ADP/communications  work 
load  at  base  level  and  to  examine  several  alternative  teleprocessing 
configurations  and  their  costs  to  ...eet  the  projected  demand. 

The  SADPR-85  Computer  Network  concept  consolidates  all  the 
present  Base  Level  ADP  activities  into  some  11  regional  ADP  centers 
while  adding  major  new  transactional  capabilities  by  using  inter- 
active terminal-to-computer  and  small- computer  to  large- computer 
communications.  The  present  Base  Level  ADP  systems  are  provided  at 
approximately  130  Air  Force  bases,  worldwide.  At  each  typical  site 


w 

In  this  regard,  although  the  host  computers  were  from  the  same  manu- 
facturer with  very  similar  operating  systems,  their  peripheral  con- 
figurations, applications  programs,  task  scheduling,  and  support 
personnel  were  sufficiently  different  to  raise  management  concern 
as  to  cost  and  time  to  cut  over  to  a merged  system.  Problems  of 
management  accountability  for  satisfactory  performance  of  a merged 
computer  facility  were  also  of  concern. 
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there  is  a Burroughs  3500  machine  and  a UNIVAC  1050  machine.  These 
facilities  support  primarily  batch- operated  applications  programs. 
There  are,  however,  on  the  average  of  15  time- sharing  teletype  ter- 
minals (mostly  on  site)  per  computer  which  operate  in  an  elementary 
time-sharing  mode  on  relatively  static  data  bases  generated  by  the 
primary  applications. 

A variety  of  applications  programs  are  run  at  these  facilities. 
The  periodically  generated  data  cards  (or  tapes)  together  with  their 
(batch)  processing  form  "applications  systems"  which  are  supported  by 
these  computer  facilities.  The  processed  data  (i.e.,  report)  are 
then  forwarded  to  system  participants  for  any  further  processing, 
review,  management  action,  etc.  In  order  to  provide  by  example  the 
scope  of  these  activities,  some  of  the  "applications  systems"  are 
listed  below: 

B-3500  Oriented  Systems 

• Base  Engineer  Automated  Management  (BEAMS) 

• Base  Level  Mil  Pers  (BLMPS) 

• Civilian  Pay  (ADS  NY) 

• Civilian  Personnel  Management  Information  (CPMIS) 

• Computer  Directed  Training  (CDTS) 

• Customer  Integrated  Automated  Procurement  (CIAPS) 

• Maintenance  Management  Information  & Control  (MMICS) 

• Medical  Material  Management  (MMMS) 

• Vehicle  Integrated  Management  (VIMS) 

• Non-Temporary  Storage  of  Household  Goods  (ADS  NO) 

U-1050  Oriented  Systems 

• Air  Force  Standard  Base  Supply 

• Mil  Aircraft  Storage  and  Disposition  Center  Management  (MASDC) 

In  order  to  achieve  the  desired  consolidation  and  introduce  major 
new  teleprocessing  capabilities  the  study  proposed  the  following  com- 
puter network  concept: 
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The  Command- centered  Computer  Network  concept 
is  based  upon  the  idea  of  providing  the  bulk  of  Air 
Force  base-level  ADP  support  at  a few  locations. 

There  will  be  nine  processing  centers  in  the  CONUS, 
two  overseas  and  one  each  for  training  and  for  sys- 
tems development.  The  processing  centers  will  each 
include  a multiprocessor  with  a large  communications 
processor  to  handle  the  communications  interfaces. 

The  nine  CONUS  centers  will  be  interconnected  by 
wideband  communication  links  and  each  Air  Force 
installation  will  have  two  independent  access  lines 
to  this  network  of  processors. 

Each  active  base  will  be  equipped  with  a large 
minicomputer  system  for  local  processing  in  the 
event  that  a communications  failure  separates  the 
base  from  its  command  processor.  Small  minicomputers 
will  be  installed  to  assist  in  data  entry  and  retrieval. 
These  systems  may  be  dedicated  to  one  or  two  functional 
areas  or  shared,  depending  on  the  conclusions  of  the 
functional  analyses.  Data  terminals  will  be  allocated 
roughly  in  proportion  to  base  population,  with  an 
average  base  receiving  about  200  terminals. 

The  potential  advantages  of  the  Computer  Network  concept  identi- 
fied by  the  SADPR-85  study  are  as  follows: 

(a)  Powerful,  multiprocessing  systems  with  re- 
dundant components  can  provide  higher  availability 
and  reliability  than  smaller,  free-standing  proces- 
sors . 

(b)  Significant  reductions  in  operations  personnel 
can  be  realized. 

(c)  A broader  range  of  specialized  functions  pro- 
vide great  flexibility  in  application. 

(d)  A simplified  command  management  is  facilitated 
by  the  use  of  a few,  interconnected,  processors  that 
enable  a small  number  of  systems  which  can  support  all 
functions  for  all  units  belonging  to  a command. 

(e)  Fewer  facilities  are  required,  reducing  sys- 
tem costs. 

(f)  Maintenance  and  control  of  software  is 
easier  since  there  are  fewer  sites. 

In  addition  to  direct  cost  savings  of  the  expected  reduced 
manning  requirements*  of  item  (b)  above,  qualitative  benefits  are 

sV  " 

A model  for  estimating  Manual  Information  Handling  (MIH)  man-hours 
per  day  consumed  by  the  Air  Force  indicates  a reduction  by  approxi- 
mately 50%  over  current  levels  through  use  of  improved  ADP  systems. 
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expected  in  light  of  the  limited  expected  availability  of  trained 
manpower  in  the  1980-90  time  frame. 

b.  Conceptual  Configuration.  The  Host  Regional  and  Satellite 
Base  configuration  concept  is  shown  in  Figs.  6a  and  6b.  The  hard- 
ware characteristics  envisioned  are  shown  in  Table  2.  The  projected 
CONUS  network  interconnection  is  shown  in  Fig.  7.  There  is  also  con- 
nected to  CONUS  a Pacific  subnetwork  with  processing  center  at  Hickam 
AFB  and  a European  subnetwork  with  processing  center  at  Ramstein, 
Germany.  The  interbase  communications  network  utilizes  50-kbps  back- 
bone circuits  with  lower  speed  access  lines.  The  transmission  and 
switching  concept  is  based  on  ARPANET  packet  technology.  The  communi- 
cation subsystem  concept  has  been  developed  to  allow  for  potential 
utilization  of  AUTODIN  II  (next  section). 

TABLE  2.  COMPUTER  NETWORK  CONFIGURATION  (Ref.  2) 

Network  Processing  Centers  (11) 

1 Multiprocessor  (8  MB  main  memory) 

6-10  Billion  byte  disk  memory 
12  Magnetic  tape  drives 
1 Computer  Output  Microfilm  unit 
1 High-performance  batch  terminal 

1 Large  communications  processor  (128  Kbytes  main  memory) 

100  Mbytes  disk  memory 

Major  Bases  (103) 

1 Large  minicomputer  system  (64  Kbytes  main  memory) 

200  Mbytes  disk  memory 

2 Small  minicomputer  systems  (32  Kbytes  main  memory) 

5 Mbytes  disk  memory  each 

1 Coaxial  cable  system  including  network  controller 
1 ATP  communications  processor 
1 Interface  Message  Processor 
1 High-performance  batch  terminal 
1 Key-disk  data  entry  system 
75-335  Data  terminals 
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FIGURE  6b.  Host  Computer  Network  Processing  Center  Configuration  (Ref.  2) 


FIGURE  7.  Proposed  SADPR-85  Network 
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The  on-base  communications  envisions  installation  of  a looped 
very-high-speed  (1  Mbps)  coaxial  cable  utilizing  time-division  multi- 
plexing techniques  wherein  each  on-base  subscriber  accesses  the  cable 
through  a Subscriber’s  Digital  Interface  Unit  (SDIU).  The  very  high 
transmission  speed  in  comparison  to  any  user's  needs  alleviates  inter- 
face and  timing  problems.  The  Spider  system  at  BTL  (Ref.  10)  .has  been  \ 

operating  successfully  utilizing  this  approach. 

c.  System  Features.  The  overall  desired  ’’writer- to- reader" 
response  time  objective  for  the  highly  interactive  teleprocessing 
modes  of  operation  is  2 sec.  Considerably  more  delay  is  tolerable 
for  bulk-type  data  transfer  (e.g.,  files).  The  overall  security 
level  objective  would  appear  to  be  no  more  than  Secret  which,  if 
not  upgraded,  would  considerably  mitigate  the  ComSec  requirements 
(and  costs).  The  impact  of  less  stringent  security  on  the  host  com- 
puter facilities  is  not  clear  as  privacy- type  issues  may  be  impor- 
tant (e.g.,  personnel  and  medical  data  are  involved).  At  present, 
only  the  obvious  can  be  said  in  that  the  criteria  and  standards  for 
privacy  can  be  quite  different  (and  presumably  less  stringent)  than 
those  for  multilevel  security. 

Some  of  the  software  features  to  be  provided  at  the  major 
Regional  sites,  as  stipulated  in  Ref.  2,  are  as  follows; 

(a)  A Generalized  Data  Base  Management  System 
(CODASYL  Data  Base  Task  Group  standard  or  equivalent). 

(b)  A high  degree  of  integrity  for  all  files 
(protection  from  accidental  damage),  and  a capability 
for  continued  effective  operation  in  the  event  of 
some  processor  or  memory  failures. 

(c)  A variety  of  mathematical  packages  including 
linear  programming  and  integer  programming  (required 
for  scheduling  systems). 

(d)  Several  special  packages  such  as  text  editing 
to  support  report  generation  and  computer  aided  in- 
struction to  support  training  systems. 

d.  Economic  Comparison.  In  order  to  gain  a perspective  on  the 
communication  subnetwork  in  relation  to  the  computer  (ADP)  and  util.- 


components  developed  in  the  SADPR-85  study  (Ref.  2)  of  four  major 
system  alternatives.  These  alternatives  are  as  follows: 


Baseline  - Respond  to  Individual  Program  Developments 
as  needed--continues  present  approach.  Replace 
components  and  augment  installations  site-by-site 
as  needed.  Acquire  more  interactive  terminals. 

Augmented  Baseline  - Enhance  baseline  approach  with 
increased  use  of  remote  terminals,  com  front  ends, 
utilize  present  circuit  switched  com  facilities. 

Base  General  - Further  develop  base  centered  system 
using  remote  interactive  terminals  and  add-on 
digital  data  communication  subsystem. 

Computer  Network  - Replace  current  system  with  new 
totally  integrated  teleprocessing  system.” 


The  cost  data  presented  herein  are  abstracted  directly  from  the 
SADPR-85  study.  No  attempt  was  made  to  review  or  verify  the  accuracy 
of  these  cost  data  nor  is  it  the  intent  herein  either  to  endorse  or 
critique  the  SADPR-85  study  results. 


Most  of  the  SADPR-85  projected  ADP  hardware  and  communication 
costs  are  made  on  a rental  or  leased  basis  and  the  cost  data  do  not 
include  discount  values  or  inflation  factors.  To  gain  insight  on  the 
relations  between  communication,  computer,  and  utilization  costs,  the 
absolute  values  of  the  cost  elements  are  of  less  importance  than  the 
cost  relation  between  these  elements.  Consequently,  cost  elements 
are  compared  here  on  a percentage  basis.  Tables  3 and  4 show  the 
expected  cost  components  as  a percentage  of  the  projected  total  15- 
year  cost  (1974-90)  for  each  alternative.  In  Table  3,  the  cost  ele- 
ment is  shown  as  a percentage  of  the  total  cost  of  its  associated 
alternative*  which  is  shown  in  the  lower  portion  of  the  table.  Table 
4 provides  a further  breakdown  of  the  communications  system  life-cycle 
cost  components  of  the  Computer  Network  (alternative  4)  costs.  For 


Comparisons  between  any  two  alternatives  should  be  further  adjusted 
by  the  ratio  of  alternative  costs. 


r 


TABLE  3.  SADPR-85  (Ref.  2)  COMPONENT  LIFE-CYCLE  COST  ESTIMATES 
(1975-90)  AS  PERCENTAGE  OF  TOTAL  COST 


(Exclusive  of  Base 

Operation  Support) 

Alternative 

Cost  ComDonent 

H 

Baseline 

#2 

Augmented 

Baseline 

#3 

Base  Genera] 
(phase  down* 
ComDonent ] 

#4 

Computer  NetwcrV 
(phase  down* 

comoonent ] 

— 

Sys  Engr  & Mgmt 

0.05% 

0.2% 

2.  7% 

3.2% 

ADP  Equipment 

30 

39 

29 

32  (20) 

Communications 

0.8 

0.7 

4.6  (0.3) 

7.3  (0.4) 

Software** 

0.4 

0.4 

4 (0.1) 

4.4  (0.1) 

O&M 

39 

59 

59  (28.4) 

S3  (30) 

Facility  Support 

0.1 

0.1 

0.8  (0.1) 

0.5  (0.2) 

TOTAL,  $M 

(phase  down*  equipment) 

1909 

2213 

1944  (839) 

1677 

(839) 

Base  Operation  Support,  $M 

184 

184 

175 

135 

GRAND  TOTAL,  $M 

2093 

2397 

2119 

1812 

Approximate  Manning  Level 

5000 

5000 

4000 

2000 

it 

Cost  of  operating  present 
in  parenthesis. 

system  while 

implementing 

this  alternative.  This 

value  is 

shown 

it  it 

Includes  cost  estimate  of  recoding  current  COBOL  applications  programs. 


TABLE  4.  SADPR- 
COMMUNICATION 
COMMUNICATION 

Cost  Category 

-85  (Ref.  2)  ESTIMATED  LIFE-CYCLE  (1975-90) 
COMPONENT  COSTS  AS  A PERCENTAGE  OF  TOTAL 

COST  ($116M)  OF  COMPUTER  NETWORK  CONCEPT 
(Alternative  4 Above) 

On-Base  Percent  Inter-Base  Percent  Net  Percent 

Processor 

28  % 

7.5% 

35.5% 

Crypto 

5.5 

.8 

6.3 

Circuits 

12.2 

22.3 

34.5 

Other  Equipment 

10 

10 

Associated  Support 

1.6 

1.6 

Maintenance 

11.7 

0.4 

12.1 

TOTAL 

69 

31 

100  = $116] 

the  Base  General  and  Computer  Network  alternatives,  the  current  ADP 
facilities  will  have  to  be  maintained  while  these  systems  are  brought 
on-line.  Thus,  there  is  incurred  a phase-down  cost  of  the  current 
facilities  which  must  be  added  to  the  implementation  costs.  This  is 
reflected  in  Table  3.  It  can  be  seen  that  the  phase-down  costs  are 
almost  as  much  as  the  acquisition  costs.  The  expected  annual  costs 
are  shown  in  Fig.  8. 
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FIGURE  8.  Comparison  of  SADPR-85  Total  Program  Costs  ( FY  1974  Dollars) 
for  Base  General  and  Computer  Network  Alternatives  (Ref.  2) 


The  cost  comparison  among  the  four  SADPR-85  alternatives  con- 
sidered indicates  the  allowing: 

• There  is  no  major  variation  in  expected  total  life-cycle 
costs  between  the  alternatives  considered.  The  phase-down 
costs  associated  with  alternatives  3 and  4 offset  the 
savings  incurred  through  using  advanced  technology. 

• For  alternatives  3 and  4 the  principal  cost  uncertainty 
would  appear  to  reside  in  the  needed  time  to  achieve 
successful  operational  status.  Delays  will  seriously 
impact  estimated  phase-down  costs.  The  principal  lever- 
age elements  can  be  expected  to  be  communication  inter- 
faces and  ADP  software. 

• The  O&M  as  a percentage  of  total  cost  per  alternative 
also  does  not  vary  greatly;  the  projected  variations  in 
total  cost  are  matched  by  corresponding  variations  in 
O&M  costs  through  changes  in  manpower  levels. 

Figure  9 shows  the  expected  system  component  costs  (Ref.  2)  for  the 
Computer  Network  (alternative  4)  in  annual  expenditures  (not  including 
the  phase-down  costs)  in  years  after  a go-ahead  decision  (postulated 
as  1974).  Here  the  cost  components  are  shown  as  additive  increments. 
This  figure  replicates  one  in  the  SADPR-85  report  but  further  decom- 
poses the  communications  cost  in  order  to  contrast  on-base  and  long- 
haul  communications  costs. 

The  long-haul  inter-base  communications  and  some  portion  of  the 
on-base  communications  processor  functions  could  be  supported  by  a 
common-user  switched  data  system  such  as  the  proposed  AUTODIN  II 
(Ref.  1).  The  rest  of  the  on-base  communications  are  provided  by  the 
very  high  speed  local  coaxial  distribution  system.  The  on-base  portion 
shows  a cost  buildup  at  +4  years  due  to  the  purchase  of  the  local 
coaxial  system  which  tapers  off  to  sustaining  costs  at  +11  years. 

The  inter-base  communications  and  on-base  communications  processors 
will  be  leased  and  their  cost  builds  up  to  a relatively  constant 
annual  level  by  +7  years  when  the  system  enters  into  significant 
operations . 

Several  revealing  time  dependent  trends  are  shown  in  Fig.  9. 

During  the  initial  phase  the  software  costs  dominate  and  then  (it  is 


expected)  trail  off  to  a support  role.  The  first  significant  hard- 
ware costs  are  those  associated  with  acquiring  local  communication 
facilities,  then  followed  by  the  ADP  hardware  acquisition.  Long-haul 
communications  costs  are  incurred  last.  During  the  very  earliest 
portion  of  ADP  hardware  acquisition  (+5  to  +6),  the  long-haul  plus 
on-base  com  processor  costs  match  tha:  of  the  ADP  hardware  but  the 
sum  of  these  costs  is  still  dominated  by  the  software  and  on-base 
com  costs  individually.  Past  this  period  (i.e.,  by  +7)  the  system 
is  beginning  operations  and  the  O&M  costs  dominate  all  else. 

e.  Discussion.  In  Table  5 aggregated  costs  for  a few  key  years 
are  shown  in  contrast  with  the  total  system  life  costs  (not  including 
phase-down  costs).  For  each  year  (or  total  life  cost)  the  aggregates 
are  shown  as  a percentage  of  that  year’s  (or  total  life)  cost.  With 
the  exception  of  the  communications  aggregate,  it  is  striking  to  see 
the  relatively  small  fluctuation  in  aggregate  percentage  cost.  More- 
over, that  communications  component  (i.e. , inter-base  plus  on-base 
processor),  which  is  capable  of  being  provided  by  a common-user 
switched  data  system,  does  have  a constant  proportion  of  the  annual 
(life-cycle)  costs. 

Although  a critical  technical  element  of  the  computer  network 
concept,  the  communications  direct  cost  element  would  not  appear  to 
have  large  leverage  on  system  cost.  It  is  the  indirect  impact  of 
communications  that  is  most  significant.  Timely  availability  with 
satisfactory  performance  (delay,  error  rate,  throughput)  of  the  com- 
munications portion  is  of  considerable  consequence.  The  communications 
common-user  assignable  portion  of  the  system  costs  is  on  the  order 
of  one- third  to  one-fourth  that  of  the  ADP  assignable  costs.  From 
this  point  of  view,  this  portion  of  the  communications  cost  appears 
significant.  When  the  O&M  costs  (mostly  personnel)  are  included,  the 
common-user  assignable  communication  costs  drop  to  less  than  10  per- 
cent. 
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COSTS  FOR  SADPR-85 

(Ref.  2) 

COMPUTER 

NETWORK  ALTERNATIVE 

Cost  Group 

(1980) 
+ 6 

Year 
(1982) 
+ 8 

(1988) 

+14 

Total  Life 
Cost 

ADP  + Software 

27% 

26% 

3 3% 

33% 

Com  Total 

24% 

16% 

11% 

14% 

On-Base 

16% 

7% 

2% 

6% 

Inter-Base  Plus 
On-Base  Compressor 

8% 

9% 

9% 

8% 

O&M  + Sys.  Engr. 

45% 

57% 

54% 

52% 

(Sys.  Engr. ) 

(12%) 

( 6%) 

( 3%) 

( 6%) 

Other 

4% 

1% 

2% 

1% 

Total  Expected 

48 

72 

72 

$838M 

Annual  Cost,  $M/yr 

The  ComSec  requirements  considered  by  the  SADPR-85  study  resulted 
in  minimal  costs.  From  Table  4,  the  ComSec  component  of  the  communi- 
cation costs  (crypto)  amounted  to  6.3  percent  of  the  total  computer 
network  communications  cost  or  equivalently  0.6  percent  of  the  total 
cost.  Those  teleprocessing  systems  having  more  stringent  ComSec  re- 
quirements could  experience  considerable  escalation  in  the  communi- 
cations cost.  Reference  1 indicates  that  stringent  ComSec  requirements 
could  double  the  communications  cost.  This  would  raise  the  common-user 
communication  assignable  costs  to  a par  with  ADP  costs  but  these  costs 
would  still  be  dominated  by  the  personnel  costs. 

The  economic  results  of  the  SADPR-85  study  are  very  illuminating 
for  placing  into  perspective  the  relative  roles  of  ADP,  communications, 
and  operating  costs.  However,  it  must  be  borne  in  mind  that  the  systems 
considered  are  quite  large  and  extensive.  For  significantly  smaller 
teleprocessing  systems  (i.e.,  systems  not  of  themselves  aggregated 
into  larger  systems),  the  communication  cost  component  can  be  a sig- 
nificantly larger  portion  of  the  cost. 
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In  contrast  to  the  previously  discussed  corporate  merger  example, 
the  SADPR-85  concept  represents  a more  comprehensive  and  advanced 
usage  of  teleprocessing  functions.  The  users  are  considerably  more 
distributed  with  considerably  more  ’’applications  systems”  consoli- 
dated. The  Computer  Network  concept  incorporates  consolidation  of 
computer  functions  which  was  not  pursued  in  the  corporate  merger 
example.  Although  each  regional  processor  uses  a star-like  topology, 
the  regions  themselves  are  interconnected  with  a distributed  switched 
backbone  network. 

The  Computer  Network  concept  would  support  a well-defined  common 
community  of  Air  Force  users  (on  a geographical  basis).  Further,  the 
concept  envisions  implementation  of  a new  system  with  a maximum  of 
flexibility  in  design.  As  with  the  WWMCCS  ADP  buy,  the  possibility 
exists  for  common  acquisition  of  processor  hardware  and  associated 
operating  systems  at  the  Regional  Processing  sites.  This  will  provide 
a relatively  homogeneous  ADP  environment  to  the  network,  even  more  so 
than  the  WWMCCS  sites  as  there  is  more  replication  of  the  Applications 
Programs.  Finally,  a central  System  Engineering  focus  can  be  estab- 
lished which  would  ensure  compatible  development  of  system  standards, 
interfaces,  protocols,  and  software  support. 

Although  the  SADPR-85  Computer  Network  concept  enjoys  the  design 
advantages  of  starting  from  scratch  with  a new  system,  there  are, 
nonetheless,  several  challenging  areas  of  technical  development  and 
operational  usage.  These  are  not  unique  to  the  SADPR-85  concepts. 
Rather,  they  are  generic  to  all  teleprocessing  systems  with  computer 
resource  sharing  features.  These  problems  devolve  from  the  usage  of 
the  system  and  relate  to  network  control,  resource  scheduling,  task 
priorities,  and  so  forth  (see  Section  III).  Another  major  element 
will  be  the  problems  of  multiaccess  by  diverse  users  of  distributed 
data  bases,  e.g.,  file  structures,  accessibility,  interactions,  and 
up-dates,  etc.  Finally,  as  with  the  SATIN  IV  system  discussed  in 
Section  III-B-1,  there  is  a technically  related  problem  to  multilevel 
security  although  the  level  of  protection  required  may  be  relaxed. 

In  this  regard,  the  emphasis  would  fall  into  the  area  of  privacy  of 


privileged  data  such  as  personnel  files.  However,  concern  could 
develop  about  intelligence  information  that  can  be  derived  from  data 
regarding  supply,  maintenance,  status,  and  distribution  of  forces  and 
assets. 

5.  Proposed  AUTODIN  II  Network 

a.  Synopsis . The  AUTODIN  II  (also  referred  to  as  IDN)  is  a 
proposal  by  the  DCA  to  acquire  an  ADP  subscriber-oriented,  common-user, 
switched  data  transmission  system  (Ref.  1).  By  emphasizing  quick  re- 
sponse, AUTODIN  II  would  provide  inquiry  response  ana  interactive 
data  transmission  not  available  with  AUTODIN  I.  In  very  general 
terms,  the  AUTODIN  II  concept  is  similar  to  the  newly  emerging  Value 
Added  Networks*  (VANs)  such  as  TYMNET,  Packet  Communications,  Inc., 
TELENET,  and  GRAPHNET.  However,  AUTODIN  II  will  have  to  provide 
communication  security  features  not  present  in  the  VANs.  The  basic 
technology  concepts  for  AUTODIN  II  are  derived  from  ARPANET  and  are 
thus  similar  to  the  expanded  FWIN  concept  discussed  previously. 

Whereas  the  principal  objective  of  the  (possibly  expanded)  PWIN** 


So  called  because  these  networks  lease  basic  transmission  facilities 
from  the  communications  Common  Carriers  and  add,  at  nodal  points, 
switching  and  data  subscriber  interfacing  services. 

PWIN  could  be  in  use  well  before  AUTODIN  II  would  achieve  opera- 
tional status.  The  present  planning  concept  is  for  the  WWMCCS  ADP 
sites  to  transition  over  to  using  AUTODIN  II  when  it  becomes  opera- 
tional and  phase  out  the  (expanded)  PWIN  assets  not  incorporated 
into  the  AUTODIN  II  network.  This  transition  may  become  more  chal- 
lenging than  expected  depending  on  PWIN  R&D  evolution  and  accommo- 
dation to  problems  unique  to  WWMCCS  ADP  sites.  For  successful 
support  to  the  WWMCCS  ADP  sites,  AUTODIN  II  will  have  to  support 
Type  lb  features  discussed  in  Section  III-B. 
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is  to  perform  operationally  oriented  teleprocessing  experiments  within 
the  WWMCCS  ADP  community,  the  objective  of  AUTODIN  II  is  to  serve  as 
a subscriber-oriented,  general-purpose,  common-user  switched  data 
communications  network  in  support  of  and  shared  by  many  teleprocessing 
systems.  Although  AUTODIN  II  may  be  required  to  have  the  capability 
to  support  Type  I applications,  it  is  discussed  here  because  its 
largest  class  of  subscribers  can  be  expected  to  be  from  the  Type  II 
applications  area. 

The  AUTODIN  II  broad  concept  of  design  and  operations  is  similar 
to  the  ARPANET  philosophy  wherein  the  data  transmission,  switching, 
and  control  functions  are  separated  from  the  ADP  and  terminal  func- 
tions. Host  computers  and  user  terminals  would  utilize  the  AUTODIN 
II  as  subscribers  with  the  obligation  of  modifying  as  necessary  their 
site  hardware,  software,  and  procedures  in  order  to  match  the  AUTODIN 
II  interface  standards,  operating  protocols,  and  flow  control.  This 
approach  of  data  transmission  is  distinctly  different  from  the  con- 
ventional practice  of  acquiring  communications"  as  a component  of 
any  specific  integrated  computer /terminal  teleprocessing  system.  In 
current  systems,  the  data  standards,  protocols,  and  automated  opera- 
ting procedures  are  under  the  full  control  of  the  specific  system, 
usually  the  host  computer(s). 

The  AUTODIN  II  proposes  to  utilize  a distributed  set  of  packet- 
type  switching  nodes  interconnected  with  50-  to  56-kbps  backbone  data 
transmission  lines  as  shown  in  Fig.  10.  Each  subscriber  (computer 
and  terminal)  accesses  the  system  through  one  (closest)  or  more  (for 
redundancy)  switching  nodes  in  the  arrangement  as  shown  in  Fig.  11. 
Each  subscriber  will  enter  the  switch  through  an  access  line  to  the 
Communications  Access  Processor  (CAP)  component  of  the  switch.  The 


Usually  dedicated  lines  leased  from  a Common  Carrier  telephone 
company  and/or  dial-up  telephone  lines.  Higher  than  voice  capacity 
(i.e.  , 4.8  to  9.6  kbps)  transmission  can  also  be  leased  on  a dedi- 
cated point-to-point  (i.e.,  nonswitched)  basis. 


FIGURE  10.  Proposed  AUTODIN  II  System  (see  also  Refs. 
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FIGURE  1 1 . Proposed  AUTODIN  II  Access  Arrangements  (see  also  Refs.  1 and  5) 


CAP  will  serve  as  the  interface  point  and  service  a number  of  types 
of  line  and  line  speeds  varying  from  75  bps  up  to  9.6  kbps  and  special 
higher  speed  lines.  The  CAP  will  service  synchronous  and  asynchronous 
lines  with  several  of  the  more  common  data  standards  and  protocols. 
Additionally,  the  CAP  will  have  to  exercise  certain  subscriber  access 
control  functions  to  achieve  network  flow  control.  It  is  not  known 
yet  whether  polling- type  access  lines  will  be  utilized. 
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An  interesting  result  of  the  study  in  Ref.  1 is  the  estimated 
projection  of  the  number  of  DoD  terminals  and  their  location  relative 
to  ADP  sites.  In  CONUS,  there  were  estimated  to  be  in  the  1980  time 
frame  16,000  terminals  located  at  ADP  facilities  and  1,800  located 
remotely  from  an  ADP  site.  Overseas  these  numbers  are  reduced  by 
a factor  of  10.  Additional  information  from  Ref.  1 regarding  pro- 
jected numbers  of  computer  subscribers  is  given  in  Section  IV.  For 
these  terminals,  Ref.  l estimates  the  use  in  CONUS  of  somewhat  in 
excess  of  2,500*  access  lines  to  the  AUTODIN  II  backbone  and  560* 
access  lines  overseas.  The  access  lines  were  broken  into  two  cate- 
gories, local  and  long  distance.  The  average  length  of  a local  line 
is  15  miles  while  long  distance  lines  average  118  miles  in  CONUS, 

481  miles  in  Europe,  and  922  miles  in  the  Pacific  area.  From  Ref.  1 , 
the  projected  total  number  of  DCS  circuits  for  1978  and  their  speed 
categories  to  support  the  AUTODIN  II,  both  the  backbone  and  access 
portions,  are  given  below: 

CONUS  Overseas 


Wideband  (>  9.6  kbps) 

118 

16 

High  Speed  (600  to  9.6  kbps) 

1121 

316 

Low  Speed  (<  600  bps) 

1714 

375 

The  packets  are  structured  as  shown  in  Fig.  12.  Each  subscriber 
will  have  the  responsibility  of  structuring  his  information  into  seg- 
ments which  are  sent  to  the  CAP  on  the  switch.  The  switch  then  further 
breaks  the  segments  into  packets  which  are  routed  and  sent  out  sepa- 
rately over  the  network  to  a destination  switch.  There  the  packets 
are  reassembled  into  a segment  and  then  the  segment  is  delivered  to 
the  destined  subscriber.  Segments  are  prioritized  and  classified  by 
length  and  function  into  five  categories;  interactive,  inquiry/re- 
sponse, data  base  update,  Bulk  1 and  Bulk  2. 


VC 

Many  terminals  will  utilize  more  than  one  access  line  to  the  back- 
bone  network,  either  for  redundancy  or  a high-  and  low- speed  line. 
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I 


l 


• SEGMENT 


LEADER 


INFORMATION  I TO  8000  BITS 


ERROR 

CONTROL 


• PACKET 


START 

FRAMING 


HEADER 


INFORMATION  1 TO  1000  BITS 


ERROR 

CONTROL 


ENDN 
FRAMING^ 


Taken  from  material  presented  10  July  1974  by  the  DCA  to  DTACCS  Advisory  Panel. 

2-12-75-12 

FIGURE  12.  Proposed  AUTODIN  11  Data  Handling  (see  also  Refs.  1 and  5) 


Segment  assembly,  error  control,  and  certain  other  logical  func- 
tions are  the  responsibility  of  the  AUTODIN  II  network.  Structuring 
the  segments  and  providing  a compatible  operating  interface  to  network 
standards  (including  the  logical  protocols  for  access  control)  will  be 
the  responsibility  of  the  subscriber.  Within  the  network  (CAP  access 
to  CAP  egress),  multilevel  ComSec  is  provided.  The  speed  of  delivery 
objective  from  acceptance  of  an  interactive- type  segment  at  the  CAP 
to  the  start  of  segment  delivery  to  the  destination  subscriber  is  one 
second.  The  objective  for  inquiry /response  and  Data  Base  update  is 
on  the  order  of  seconds  to  a minute  while  the  Bulk  categories  can  be 
delayed  up  to  hours. 

b.  Discussion.  With  the  brief  description  of  AUTODIN  II  given 
above,  several  observations  are  possible.  Internal  to  the  network, 
the  data  system  is  very  homogeneous.  However,  the  network,  in  order 
to  be  common-user,  must  be  able  to  interface  a very  heterogeneous  set 
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of  subscribers.  The  primary  responsibility  for  this  interface  is 
undertaken  at  the  CAP  portion  of  the  switch  with  secondary  responsi- 
bility assumed  by  the  subscriber.  (His  software  must  be  capable  of 
supporting  the  necessary  data  formating  and  logical  dialogue  with 
the  CAP  portion  of  the  packet  switch,  e.g.,  busy,  acknowledge,  status, 
etc. ) 

The  principal  potential  advantages  foreseen  for  AtlTODIN  II  are 
as  follows; 

• A standard  switched  data  transmission  service  with  wide 
geographic  coverage. 

• Communications  optimized  for  interactive  data  transmission. 

• Economics  of  scale  for  long-haul  communication  transmission 
costs  achieved  through  shared  trunk  lines.* 

• Increased  reliability  through  a distributed  multiple  con- 
nected network. 

• Network  design  and  growth  depending  principally  on  total 
aggregated  network  traffic  with  relatively  low  sensitivity 
to  detailed  traffic  requirements  between  subscriber  pairs. 

• Facilitate  ADP  resource  sharing:  hardware,  software,  data 
bases,  etc. 

In  addition  to  potential  communication  cost  savings  for  small  to 
moderately  sized  systems  oriented  to  supporting  interactive  ADP  func- 
tions , AUTODIN  II  type  network  would  provide  a facility  for  inter- 
connecting sites  from  differing  "systems,"  which  only  have  intermit- 
tent need  to  exchange  data.  That  is  to  say,  the  AUTODIN  II  could 
itself  serve  as  an  interface  between  teleprocessing  systems.  The 
current  AUTODIN  I system  serves  this  purpose  for  the  present  batch 
and  file-transfer-oriented  ADP  systems.** 


In  the  DoD  context , additional  savings  m ComSec  equipment  may 
also  accrue. 

*0r  semi- interactive  systems  for  which  relatively  long  delays 
(minutes)  can  be  tolerated. 
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Achieving  a successful  AUTODIN  II  is  not  without  risks.  These 
can  be  categorized  as  network  oriented  and  subscriber  impact.  With 
regard  to  the  network  itself,  the  principal  technical  challenges 
appear  to  reside  in  the  following: 

• Achieving  adequate  multilevel  security  at  acceptable  cost 

• Providing  flow  control  and  managing  network  capacity 

• Establishing  adequate  subscriber  data  interface  standards. 

Critical  to  the  successful  acceptance  by  subscribers  of  any  common- 
user  data  network  are  issues  relating  to  the  network  impact  on  current 
and  near-term  future  computer  sites.  Some  of  these  are: 

• Relative  transparency*  of  the  network  to  the  subscribing 
ADP  facility 

• Adequate  availability  of  needed  network  capacity  and 
throughput 

• Minimum  adjustment  to  site  operating  system  software 

• Minimum  external  impact  on  control  of  site  assets-- 
hardware,  software,  and  data  bases 

• Maintenance  of  site  responsibility  for  its  ADP  tasking 
priorities,  accessibility,  data  integrity  (files) 

• Heterogeneity  in  candidate  subscriber  ADP  site  con- 
figurations and  workload. 

Satisfactory  transparency  and  associated  throughput  performance  for 
one  computer  installation  need  not  be  acceptable  for  another.  Nor  is 
it  clear  that  a given  network-wide  set  of  data  transmission  standards 
exists  for  which  efficient  throughput  and  transparency  are  mutually 
compatible  for  all  or  a majority  of  practical  site  configurations. 

The  subscriber-oriented  problems  described  above  pertain  princi- 
pally to  already  installed  systems . With  the  emergence  of  a satis- 
factorily performing  switched  data  network  with  sufficiently 


X 

A simply  stated  word  which  is  as  complex  as  "survivability"  in 
implication  and  evaluation.  This  is  discussed  further  in  Sections 
V and  VII. 
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widespread  and  accepted  data  standards , new  ADP  installations  could 
more  readily  connect  to  the  network.  With  normal  growth  and  evolu- 
tion at  the  older  ADP  sites,  they  too,  in  time,  could  be  expected 
to  reconfigure  site  hardware  and  reprogram  software  in  order  to  avail 
themselves  of  a common-user  data  network. 

c.  Potential  Economies  of  Scale  Comparison.  The  costing  data 
in  Ref.  l for  the  AUTODIN  II  concept  are  not  final  as  the  system 
configuration  alternatives  are  still  under  study.  However,  the  over- 
all magnitude  of  the  cost  estimate  is  of  some  interest  for  preliminary 
comparative  purposes  with  the  SADPR-85  communications  cost  estimates. 
The  purpose  of  such  a comparison  is  principally  to  obtain  some  esti- 
mate of  the  economy  of  scale  in  potential  cost  savings  involved  in 
long-haul  switched  data  communications.  It  is  not  unreasonable  to 
attempt  such  a comparison  as  the  communication  networks  resemble 
each  other  qualitatively,  even  though  AUTODIN  II  is  quantitatively 
much  the  larger.  Both  system  have  comparable  geographic  span,  and 
utilize  50-kbps  trunk  data  circuits  and  packet- switching  technology. 
The  SADPR-85  communications  support  some  11  major  sites  of  computer 
facilities  while  AUTODIN  is  sized  to  support  a projected  number  of 
375  ADP  facility  sites.* 

The  component  cost  comparisons  between  SADPR-85  computer  network 
communications  and  AUTODIN  II  are  shown  in  Table  6.  Here  the  SADPR-85 
ten-year  cost  estimates  are  based  on  the  1976-85  period  costs  for  com- 
parison purposes.  No  discounted  cost  figures  are  used  for  either  sys- 
tem. Note  that  a critical  cost  component  is  that  associated  with  O&M 
manning  costs  for  supporting  ComSec  requirements.  In  the  SADPR-85 
concept,  the  communications  switching  function  is  performed  by  the 
computer  front-end  processors  collocated  with  the  computer  facility. 
Only  the  total  facility  O&M  was  costed.  Consequently,  the  SADPR-85 
cost  estimates  do  not  display  any  significant  O&M  costs  in  support 
of  communications  which  is  directed  in  support  of  the  switches  and 

* 

The  projected  future  ADP  technology  and  context  used  appear  to  be 
similar  in  both  SADPR-85  and  AUTODIN  and  are  summarized  in  Section 
VI  and  Appendix  B.  This  projection  tends  to  be  conservative. 
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ComSec.  Applying  the  O&M  to  switch  cost  ratio  from  the  AUTODIN  II 
system  to  the  $33M  of  the  SADPR-85  system  yields  for  comparison  pur- 
poses an  estimate  of  $8M.  SADPR-85  shows  no  significant  ComSec- 
related  O&M,  principally  on  the  presumption  that  EATTON  technology 
will  be  available.  On  the  other  hand,  AUTODIN  II  costing  does  not 
make  this  assumption  and  uses  conventional  equipment.  This  incurs 
significant  ComSec-related  O&M  costs.  Utilizing  EATTON  on  AUTODIN  II 
could  essentially  eliminate  $198M  ComSec  O&M  costs.  If  EATTON  were 
not  available  to  SADPR-85,  then  by  applying  the  ratio  of  AUTODIN  II 
ComSec  O&M  to  equipment  costs  incurred  in  AUTODIN  II  to  SADPR-85, 

$59M  in  additional  SADPR-85  O&M  ComSec  costs  would  be  incurred.  This 
is  significant  in  that  it  increases  the  SADPR-85  communication  costs 
by  40  percent. 

TABLE  6.  TEN-YEAR  (1976-85)  COMMUNICATIONS  COST-ESTIMATE 
COMPARISON  OF  AUTODIN  II  AND  SADPR-85  (Refs.  2 and  1) 


Item 

SADPR-85 

Computer  Network 
Commun i c at i on  s 

AUTODIN  II 
Tariff 

Alternative  BI 

Projected  Number  of 

11  major 

160  major 

Major  Computer  Sites 

114  overall 

375  overall 

Communications 

Circuits 

$27M 

$93M 

Comm.  Proc. /Switch 

$33M* 

$ 776M 

O&M  (Personnel) 

$8M** 

$18  7M 

ComSec 

Equipment 

$15M*** 

$50M 

O&M  (Personnel) 

$59M** 

$198M 

Total 

$142M 

$1304M 

AUTODIN 

-- 

$240M 

Other  Costs 

-- 

$63M 

AUTODIN  II  Total 

$1607M 

Leased  communication  processors  and  other  equipment 
procured. 

SADPR  O&M  costs  not  separately  identified.  Estimates 
based  on  ratios  of  AUTODIN  II  O&M/switch  costs  and 
O&M/ComSec  costs . 

Estimate  based  on  ratio  of  AUTODIN  II  ComSec  equipment/ 
circuit  costs. 
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Using  three  different  allocations  of  ComSec  costs,  the  ten-year 
costs*  of  Table  6 are  divided  by  the  expected  number  of  major  ADP 
facility  sites  and  shown  as  a yearly  average  (ten-year  costs  * 10) 
in  Table  7.  In  making  the  scale  comparison  on  a per-site  basis,  the 
assumption  is  made  that  overall  terminal  connections  and  communication 
load  correlate  directly  with  the  number  of  ADP  sites.  However,  the 
"size"  of  the  sites  should  be  taken  into  account.  For  example,  in 
SADPR,  the  11  major  facilities  support  an  aggregate  of  103  bases, 
each  having  one  large  and  two  small  minicomputers  with  a total  aggre- 
gate CPU  core  memory  per  base  of  192  kilobytes  (=  1.536  megabits). 

Of  the  375  AUTODIN  projected  sites,  215  are  small  sites  with  aggre- 
gated CPU  core  memory  under  1.5  megabits.  If  for  comparison  purposes 
these  small  sites  are  discounted  as  not  being  major,  then  only  160 
"major  sites"  are  left. 


TABLE  7.  AVERAGE  ANNUAL  COST  (in  $K)  COMPARISONS  PER  ADP  SITE 


Average  Cost/Year/Site 

Comparison 

Options 

SADPR 

AUTODIN 

II 

11  Major 

114  Total 

160  Major 

375  Total 

Sites 

Sites 

Sites 

Sites 

ComSec  Costs 
Deleted 

618 

$60 

660 

$281 

With  ComSec  (EXD)* 

755 

$73 

691 

$295 

With  ComSec 
(Conventional) 

1291 

$125 

815 

$348 

Cost  includes  estimated  Electronic  Key  Distribution  equipment 
costs  equal  to  conventional  ComSec  equipment  costs  without  06M. 


Table  7 provides  the  comparison  for  different  normalizing  values 
of  ADP  sites.  If  the  114  major  plus  small  sites  of  SADPR-85  are  com- 
pared to  the  comparative  equivalent  number  (325)  of  ADP  subscribers 
to  AUTODIN  II,  large  discrepancies  are  revealed.  In  all  likelihood, 
the  proper  comparison  is  between  the  large  or  major  ADP  sites  (11  for 

T: 

The  present  AUTODIN  I associated  costs  are  excluded  from  the 
comparison. 


SADPR  against  160  for  AUTODIN)  as  these  can  be  more  likely  expected 
to  support  the  majority  of  terminal  and  small  computer  tasked  ADP 
loads  to  the  larger  facilities.  From  this  comparison  it  appears  that 
if  the  cost  of  conventional  ComSec  O&M  can  be  avoided,  SADPR- type 
systems  are  sufficiently  large  and  extensive  that  there  may  not  be 
any  significant  overall  savings  in  system  costs  by  utilizing  a common- 
user  data  network  such  as  AUTODIN  II  (Ref.  9).  Certainly,  for  systems 
significantly  smaller  than  SADPR- 85,  the  overall  savings  in  communi- 
cation system  costs  could  be  significant. 

6.  Type  II  Sizing  and  Cost  Model 

a.  Objective.  An  example  of  the  possible  economies  of  scale  of 
Type  II  teleprocessing  systems  is  a teleprocessing  system  sizing  and 
cost  model  (Ref.  3)  developed  by  the  General  Electric  Company  for  the 
Office  of  Telecommunications  Policy,  Executive  Office  of  the  President. 
The  objective  of  the  effort  was  to  provide  an  analytical  tool  to  sup- 
port policy  formulation  (e.g.,  ADP/communications  regulatory  issues). 

Of  particular  importance  were  identification  and  exploration  of  fac- 
tors influencing  economy  of  scale.  The  work  was  performed  strictly 
in  the  civil  sector  with  no  DoD  considerations.  Nonetheless,  it  is 
representative  of  many  of  the  issues  for  Type  II  DoD  applications. 

Reference  3 is  summarized  here  principally  to  illustrate  some  of 
the  major  factors  relating  to  system  requirements  data  or  inputs  and 
the  kinds  of  system  output  tradeoffs.  The  intent  here  is  to  show  by 
example  the  kind  of  functional  economic  relations  one  would  wish  to 
develop.  The  specific  numerical  results*  quoted  in  what  follows  tend 
to  be  either  limited  or  obsolete  by  the  following  developments  since 
the  original  study. 


Two  principal  "products”  of  the  General  Electric  study  were  a com- 
puter model  and  instruction  manual  (Vols.  II  and  III  of  Ref.  3). 
These  in  large  part  are  still  useful.  However,  the  input  data  used 
to  generate  specific  results  are  dated. 

i 
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• Changes  in  communication  cost  schedules 

• Changes  in  ADP  ’’work”  mix 

• Changes  in  terminal  characteristics  (e.g.,  line  speed  and  costs) 

• Improvements  in  network  optimization  algorithims 

• Rapidly  changing  balance  between  centralized  and  decen- 
tralized as  well  as  "shared"  delivery  of  ADP  services. 

The  characteristics  (e.g.,  break  points,  asymptotes)  of  the  total  and 
component  cost  versus  "load"  curves  demonstrate  the  qualitative  points 
of  interest. 

b.  Configuration  and  Model  Concept.  In  Ref.  3 generic  tele- 
processing systems  of  a centralized  star  type  are  modeled.  The  con- 
nection between  the  user  terminals  and  a central  processing  site  is 
through  either  a tree- like  network  with  multi-drop  lines  with  points 
of  concentration  or  a ring-like  network  wherein  multiple  loops  fan 
out  from  a central  site.  The  model  presumes  that  in  any  system  all 
the  terminals  are  under  integrated  control  with  central  management. 

Any  one  terminal  "talks"  to  (or  through)  but  one  computer.  From  this 
basic  model,  the  economic  tradeoffs  of  multiplicity  of  such  systems 
with  specialization  in  ADP  job  type  and/or  geographic  span  can  be 
studied. 

The  types  of  parameters  used  in  or  produced  by  the  model  in 
Ref.  3 include; 


• The  numbers  and  types  of  terminals  required  in  each 
served  city 

• The  numbers  and  types  of  processors  in  each  computing 
center 

• The  memory  size  for  each  processor  ' 

• The  numbers  and  types  of  memory  extension  devices 
and  controllers  for  each  processor 

• The  numbers  and  types  of  file  machines  and  controllers 
for  each  center. 

■ 

Six  types  of  teleprocessing  computerized  tasks  were  used  to 
generate  data  flow  and  processor  loading.  These  were; 


Two  Message  Switching  Tasks;  The  first  task  involved 
short  information  messages  and  the  second,  TWX-type 
messages . 

An  Inquiry  Task:  This  task  was  similar  to  a stock 
brokerage  price  quotation  task. 

An  Order  Entry  Task;  This  task  was  similar  to  that 
required  for  a stock  purchase  or  sale. 

Two  Remote  Batch  Tasks;  The  two  tasks  studied  in- 
volved a customer  billing  task  and  a file  maintenance 
task. 

c.  Typical  Results.  The  computer  model  was  used  to  design  and 
develop  the  cost  of  several  differing  types  of  teleprocessing  systems. 
Although  these  systems  are  basically  of  the  star  configuration,  they 
differ  in  ADP  task  mix,  geographical  exrent,  and  subscriber  (terminal) 
distribution.  Reproduced  from  Ref.  3 are  example  results.  All  of 
the  curves  shown  are  plotted  in  abstract  normalized  units;  consequently, 
the  qualitative  characteristics  of  the  curves  are  of  interest  but  abso- 
lute values  cannot  be  taken  literally.  More  importantly,  comparisons 
between  the  curves  cannot  be  made  as  the  normalizing  procedures  vary 
from  figure  to  figure. 

For  a system  with  various  levels  of  activity,  the  model  of  Ref.  3 
lays  out  a network  and  sizes  and  costs  subscriber  terminals,  communi- 
cations, and  the  ADP  central  computer  system  or  central  station.  The 
level  of  activity  or  "load  level"  is  computed  by  a submodel  which 
relates  the  mix  of  the  six  types  of  tasks  listed  above  to  a number  of 
"fundamental"  unit  tasks.  The  unit  costs  shown  in  Figs.  13,  14,  and 
15  are  obtained  by  dividing  the  overall  cost  by  the  number  of  unit 
tasks  at  a given  load  level.  Thus,  load  level  and  unit  costs  cannot 
be  directly  compared  between  different  system  types. 

The  first  example  shown  in  Fig.  13  demonstrates  the  unit  cost 
and  its  components  as  a function  of  load  level  for  a large  central 
computer  center  located  in  the  middle  of  the  U.S.  (i.e.,  St.  Louis) 
providing  service  to  the  50  largest  cities.  The  task  mix  used  was 
100  message-switching  tasks  to  three  remote  batch  tasks.  The  load 
level  origin  of  unity  was  only  indicated  as  that  which  would  produce 


reasonable  (criteria  not  quantified)  utilization  of  equipment. 

Verbal  inquiry  indicated  that  a load  level  of  10  might  correspond 
to  the  General  Electric  time- sharing  system  level  of  operations  about 
1974,  a very  high  level  of  operations  indeed.  From  Fig.  13  the  ter- 
minals, modems,  and  local  loops  dominate  system  cost.  There  exist 
large  potential  savings*  in  these  costs  through  upgrades  in  the 
terminal  and  modem  configuration.  In  this  example,  overall  costs 
are  relatively  insensitive  to  long-haul  communication  costs  although 
there  is  as  much  as  two-to-one  variations  in  the  communication  portion 
depending  on  transmission  network. 

Another  example  of  a teleprocessing  system  examined  in  Ref.  3 
was  of  a corporate  owned  (in-house)  system  processing  all  six  tasks 
but  with  strong  emphasis  on  the  interactive  tasks  listed  above.  The 
remote  batch  tasks  were  deferred  to  after  business  hours  (Fig.  14). 

The  system  geographic  coverage  is  similar  to  the  previous  example. 

Here  load  level  (level  of  transactions)  is  related  to  the  number  of 
central  processing  ’'systems"  needed  at  the  central  location.  For 
medium-sized  systems,  communication  costs  dominate.  As  the  load  level 
increases,  the  dominance  of  communications,  terminals,  and  central 
systems  costs  changes. 

A final  example  considers  a system  similar  to  the  preceding 
example  but  compares  the  consequences  of  sharing  a communications 
subnet.  Again,  a star  system  (or  systems)  centrally  located  (in 
"St.  Louis")  serves  the  50  largest  cities.  For  this  example,  the 
load  level  is  based  on  two  message-switching  tasks  and  one  on-line 
data  processing  task  (e.g. , order  entry).  The  other  on-line  task 
and  the  two  remote  batch  tasks  were  dropped  from  the  ADP  work  mix. 

In  Fig.  15  the  unit  costs  for  one  system  with  its  own  communications 
are  compared  with  and  shown  to  exceed  the  costs  incurred  by  one  sys- 
tem sharing  communications  with  nine  other  systems.  Having  all 
central  processing  systems  collocated  emphasizes  cost  savings  in 


Costs  used  in  Ref.  3 are  from  a 1972  cost  data  base. 
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communications  because  the  efficiencies  in  concentrators  and  line 
utilization  are  maximized  while  switching  tasks  are  minimized. 

However,  there  is  a more  interesting  interpretation.  First, 
for  a medium  system  (level  of  output  equal  to  unity,  which  by  corre- 
spondence with  Fig.  14  represents  one  medium- sized  central  processor 
system),  a shared  (with  nine  other  such  systems)  communication  (sub)net 
cuts  overall  costs  by  25  percent  while  the  communication  costs  are 
reduced  by  almost  a factor  of  six.  At  a tenfold  increase  in  load 
level  (level  of  output),  shared  communications  costs  are  halved  and 
still  produce  a 15  percent  reduction  in  overall  cost  per  system. 
However,  more  importantly,  if  ten  separate  medium  systems  (level  of 
output  equal  to  unity)  using  shared  communications  could  be  amalga- 
mated into  one  integrated  system  operating  at  ten  times  the  level  of 
any  one  system  and  using  an  independent  network,  then  the  per-unit 
costs  would  be  reduced  by  a factor  of  2.8  from  3.6  to  1.3  as  compared 
to  a 30  percent  savings  by  only  sharing  communications.  The  inference 
is  that  far  greater  opportunities  exist  for  cost  savings  by  attempting 
to  merge  smaller  systems  into  larger  ones  than  by  merely  sharing 
communication  facilities.  On  the  other  hand,  for  suitably  large  sys- 
tems, cost  advantages  by  sharing  communications  or  amalgamating 
processing  systems  vanish. 

D.  SUMMARY 

In  Section  III,  the  potential  applications  of  telepr  s 
have  been  classified  into  Command  and  Control  Type  I , w 
categories,  and  General  Applications,  Type  II,  in  wh 
many  possible  subcategories.  The  Type  I applicat;  r,  NC 

focused  and  were  differentiated  by  unique  features  ■ 

General  Nuclear  War  (survivability,  connectivity 
gency  Planning  (peak  capacity  demands).  The  Typ  ■ 

differ  from  Type  I in  their  emphasis  on  econor  . Tv?* 
categorized  in  many  different  ways.  Four  suer 
Organizational,  Regional,  Standard,  Technic  4V 
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of  these  modes  of  aggregation  are  also  possible  and  are  desirable. 
With  the  exception  of  the  technical  mode,  existing  ADP  systems  in 
DoD  (mostly  of  the  reporting  type)  reflect  all  of  the  other  four 
modes.  With  the  advent  of  teleprocessing,  the  technical  mode  (ADP 
activities  closely  related  in  their  technical  features)  will  gain 
importance.  No  scientifically  well-grounded  basis  has  yet  been  found 
for  matching  the  "best"  aggregation  of  systems  by  mode. 

Technically  useful  factors  for  categorizing  teleprocessing  net- 
works are  the  following: 

• Connectivity  and  data  exchange  requirements 

• Degree  of  heterogeneity  between  ADP  sites 

• Type  of  data  service  (interactive  or  bulk) 

• Capacity  (volume,  speed) 

• Special  features  (security,  priority) 


In  Table  8 a detailed  contrast  between  Type  I and  Type  II  appli- 
cations and  potential  problem  areas  is  presented.  Proposed  example 
systems  dedicated  to  each  application  area  Type  la,  lb,  and  II  are 
provided.  Within  the  Type  II  area  a common-user  switched  data  trans- 
mission network  is  presented.  An  important  issue  is  the  relation  be- 
tween system  realization  and  the  applications  area.  Should  Type  la, 
lb,  and  Type  II  be  realized  by  separate  (dedicated),  mixed,  or  inte- 
grated facilities?  If  or  where  separated,  what  are  the  interfaces 
and  interoperation  mechanisms?  As  yet  there  is  no  technically  satis- 
factory way  to  ensure  answering  such  questions. 

Without  any  positive  management  action,  it  is  likely  that  the 
current  operating  Type  II  ADP  systems  will  tend  to  retain  their  present 
affiliation  and  attempt  to  upgrade  their  capabilities  by  drawing  on  new 
technology  as  individual  systems . This  approach  does  not  seek  to 
maximize  ADP  cost  savings  through  aggregation  and  sharing  of  ADP  func- 
tions. At  some  point  in  time,  the  cost  of  a hands-off  approach  will 
be  excessive.  When  this  point  is  reached,  it  is  reasonable  to  expect 
that  evolving  operational  systems  whose  aff iliatior.s  are  sufficiently 
close  will  have  strong  economic  motivation  to  merge,  confederate,  or 
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TABLE  8.  CONTRAST  OF  TYPE  I AND  TYPE  II  APPLICATIONS 
AND  POTENTIAL  PROBLEM  AREAS 


APPLICATION  AREA 


EXAMPLE  SYSTEMS 


CHARACTERIZATION 


• General  War  C - survivablt  short -delay 
transactional  messages.  Limited  number 
host  computers;  specialized  application 
programs.  Data  naturally  packeted. 
Homogeneous  system  design. 

• AUTOVON- derived  circuits  with  AutoDial 
with  adaptive  routing/switching. 

• Economic  aspects  secondary  to  surviv- 
ability and  speea/connectivity.  Not 
general-pu rpose-ori anted . 


• Survivability-multimedia  transmission 
(Sat  VLF,  etc.  ).  Integration  at  CPs 
and  force  units. 

e WWMCCS  and  other  C3  system 
integration. 

# Logical  relation  between  AUTOVON/ 
SATIN  IV  switch. 


Expanded  PWIN  • WWMCCS  ADP-C  internet.  For  (1)  cont. 

of  ops,  (2)  distributed  data  base, 

(3)  contingency  planning.  ARPA  derived 
technology  hierarchy  of  prioritised 
services,  RJE  and  transactional. 

• Economic  aspects  on  par  with  functions. 
May  require  large  peak  factor  for  crises 
management. 

• Hardware  homogeneous,  software,  and 
configuration  heterogeneous. 


• Command  prerogatives,  data  file 
standards,  responsibility,  mixed 
access,  multilevel  security. 

• Site  software,  network  interface,  and 
schedules. 

• System  unique  contra ints. 

• Capacity  priorities/load  peaking. 

• Remote  host  computer  science. 


APPLICATION  AREA 


EXAMPLE  SYSTEMS 


CHARACTERIZATION 


Management 

Information 

Systems 


SADPR-85 

ALS 

MACIMS 
SPEEDEX 
STOCK  POINTS 


Common  User 
Data  Network 


i Emphasis  on  cost-effective  ADP  support 
to  multitude  of  military  support  activities 
e.g.,  supply,  logistics,  personnel,  finance, 
etc. 

Primarily  stand-alone  facilities  evolving 
towards  incorporating  remote  terminal 
activities.  Each  system  tends  to  be  in- 
ternally homogeneous  in  hardware  and  soft- 
ware and  externally  very  heterogeneous. 

1 System  configuration  and  operation  closely 
coupled  to  activities  supported. 


• Subscriber-oriented  common-user-switched 
digital  data  network.  Hierarchical  switched 
network  of  data  packets  with  set  of  standard 
terminal,  host  interfaces. 

• Strong  separation  of  ADP  site  operation  from 
"standard  network"  backbone. 

• Emphasis  on  economic  aspects,  throughput,  savings 
in  scale.  Provide  cost-effective  capability  and 
connectivity  for  small  to  medium  "systems." 

• May  provide  savings  in  ComSec  costs. 

• Allows  shared  resource  and  ADP  systems  inter- 
operation for  1900-90  ADP  environment. 

• May  provide  method  for  interconnecting  or 
interfacing  independent  teleprocessing  net- 
works requiring  intermittent  traffic  exchange. 

• Provide  multiple  functions:  e.g.,  query/ 
response,  transaction,  RJE,  and  file  transfer. 

• Must  operate  in  very  heterogeneous  environ- 
ment. 


Control  of  proliferation  of  systems 
and  redundant  overlap  in  function. 


, Aggregation  of  system  use,  functor 
and  design. 


• System  interoperability. 


• Multilevel  security  and  privacy. 

• Econometric  methodoloqy  and  evaluation. 

• Test  and  evaluation,  system  growth 
and  evolution. 

e System  technology  transfer,  switches, 
front-ends,  software,  etc. 

Plus  To  a Lesser  Degree 

e Development  of  interface  standards. 

• Multisystem  shared  flow  control  and 
network  control. 

• Software  impact  and  cost  allocations. 

• Network /subscriber  responsibilities. 

• Planning,  requirements  and  acquisition 
roles  and  responsibility. 

e Impact  on  ADP  suppliers  vice  ccmwnor 
or  specialty  data  carriers. 

• Policy  for  (1)  user  acceptance  or  sub- 
scription, (2)  separate  networks  and 
their  relationships  to  common  user, 
each  other. 

e Needs  adequate  RED  program. 

a Hybrid  fast-circuit  and  packet -switching 
technology  for  mixed  interactive  and 
bulk  data  traffic. 
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otherwise  attempt  to  reduce  costs  through  mutual  sharing  of  assets. 
Alternate  to  or  in  parallel  with  this  approach,  DoD  can  promote  de- 
velopment of  management  tools  (requirements),  technology  (subscriber- 
oriented  networks)  and  research  (multilevel  security  and  data  base 
management)  in  order  to  foster  earlier  aggregation  of  ADP  systems  by 
natural  means  or,  if  desired,  begin  to  lay  the  basis  for  setting  spe- 
cific objectives  for  ADP  aggregation. 

For  Type  II  applications,  preliminary  cost  data  taken  from  a 
proposed  large  and  geographically  extensive  teleprocessing  system 
for  Air  Force  base  level  ADP  (SADPR-85,  Ref.  2)  were  contrasted  with 
similar  preliminary  costs  data  for  a proposed  switched  common-user 
data  transmission  plant  (AUTODIN  II,  Ref.  1).  The  salient  features 
from  Ref.  2 would  indicate  the  following: 

• Inasmuch  as  the  proposed  system  will  replace  an  already 
existing  set  of  equipments , the  estimated  cost  of  sus- 
taining and  then  phasing  down  the  existing  facilities 
while  bringing  on  to  line  the  new  system  is  as  large  as 
the  projected  cost  of  the  new  system.  Consequently, 
overall  costs  are  extremely  sensitive  to  delay  in 
bringing  a new  system  on  line. 

• Not  including  the  cost  of  phasing  down  the  old  system, 

O&M  amounts  to  over  50  percent  of  life- cycle  costs  for 
the  new  system. 

• With  reduced  or  no  ComSec  requirements  (e.g.,  EATTON 
technology),  communication  costs  are  well  under  half 
the  ADP  costs.  For  the  total  system,  including  O&M 
costs,  the  communications  costs  account  for  15  percent 
of  the  total.  When  old  system  phase-down  costs  are 
included,  the  communications  costs  drop  to  7 percent 
of  the  total. 

• ComSec  O&M  costs  are  very  significant.  If  conventional 
ComSec  equipment  is  required,  then  O&M  in  support  of 
this  equipment  will  increase  the  projected  communications 
costs  by  at  least  40  percent. 

Preliminary  comparison  for  potential  economies  of  scale  between  the 
SADPR-85  communications  and  AUTODIN  II  reveals  that  without  ComSec 
O&M  costs  associated  with  current  equipments,  a common-user  data 
transmission  system  does  not  provide  significant  savings  in  communi- 
cations costs  over  systems  as  large  and  extensive  as  SADPR-85.  If 
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conventional  ComSec  O&M  costs  are  incurred  and  if  a common-user  trans- 
mission system  can  provide  multilevel  security,  then  a common-user 
(secure)  data  transmission  system  could  possibly  provide  up  to  40  per- 
cent reduction  in  communication  costs  in  comparison  with  a dedicated 
system  such  as  the  SADPR-85  communications.  In  any  event,  for  large 
systems,  communications  costs  are  not  dominant. 

These  preliminary  results  demonstrate  the  cost  impact  of  security 
and  highlight  an  important  cost  issue.  "Should  use  of  a common-user 
data  communication  system  be  dictated  for  potential  savings  in  communi- 
cation costs  at  the  possible  risk  of  delaying  overall  system  operations 
and  incurring  continuing  (increased)  costs  in  phasing  down  an  older 
system?”  There  is  no  easy  answer  to  such  a question.  Clearly,  the 
preexistence  of  a successful  and  secure  common-user  data  communica- 
tions system  would  strongly  motivate  tailoring  a SADPR-85  system  to 
its  use.  On  the  other  hand,  if  no  satisfactory  common-user  data  trans- 
mission system  existed  prior  to  a SADPR-85  system  implementation,  the 
opportunity  might  exist  to  grow  one*  out  of  the  dedicated  data  trans- 
mission component  of  a SADPR-type  system. 
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This  is  precisely  the  evolutionary  route  of  the  TYMNET  (Ref.  11), 
which  grew  out  of  the  TYMSHARE  system. 
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IV.  REQUIREMENTS  AND  ASSETS 


A.  REQUIREMENTS 

In  this  section,  an  overview  of  the  current  ADP  usage  and  re- 
quirements ’’data  base”  is  presented  with  the  object  of  placing  in 
perspective  the  relationship  of  current  requirements  data  to  those 
needed  for  the  design  and  management  of  teleprocessing  systems  as 
well  as  policy  formulation.  The  focus  in  this  section  is  on  the 
Type  II,  General  Applications,  teleprocessing  area.  The  Type  I re- 
quirements formulation  follows  from  a more  narrowly  defined  activity 
of  mission  function  in  support  of  NCA  direction  of  the  military 
forces.  However,  much  of  the  technically  oriented  discussion  re- 
lating to  requirements  for  system  design  is  applicable  to  Type  I 
applications. 

The  present  ADP  system  requirements  data  can  be  characterized 
as  follows: 

• List  inventories  of  ADP  Hardware  Assets 

• List  inventories  of  Reporting  or  Functional  Information  Systems 

• Preliminary  models  of  ADP  task  load  and  data  traffic  flow. 

This  section  provides  examples  and  discussion  of  these  categories. 

1.  Acquisition  Procedure  for  ADP  Hardware 

It  is  useful  to  review  and  characterize  the  present  acquisition 
procedure  for  ADP  assets  with  DoD.  It  is  this  process  which,  to  date, 
determines  the  need  and  scope  of  data  required  for  formulating  current 
ADP  requirements.  An  ADP  site  or  prospective  site  within  the  DoD 
generates  a requirements  justification,  an  applications  description, 
an  acquisition  plan,  and  a technical  specification  for  some  ADP 


hardware*  items.  This  request  is  then  reviewed  for  approval  through 
the  acquisition  chain  to  which  the  installation  belongs  usually  within 
a military  department  or  DoD  agency.  The  approval  level  needed  to  pro- 
ceed with  acquisition  is  generally  keyed  to  the  cost  of  the  buy.  Most 
full  size  computers  or  a large  buy  of  small  computers  or  associated 
equipment  are  required  to  traverse  the  full  approval  chain  to  include 
review  by  OSD  Comptroller  personnel.  For  any  particular  approved  re- 
quest, it  is  then  reviewed  to  ascertain  if  the  technical  specification 
can  be  satisfied  by  any  ADP  assets  held  in  a surplus  pool.  If  the  re- 
quest cannot  be  supported  with  surplus  ADP  assets,  the  requirements, 
specifications,  and  any  special  purchase  conditions  are  forwarded  to 
the  General  Services  Administration  (GSA)  who  then  acts  as  the  Procure- 
ment Agent**  for  DoD.  A Request  for  Proposal  (RFP)  is  issued  to  in- 
dustry, the  received  contractor  bids  are  then  technically  evaluated 
by  the  appropriate  DoD  military  department,***  and  a ranking  of  the 
bidders  is  provided.  GSA  then  proceeds  with  the  negotiation  for  pro- 
curement and  delivery  of  the  equipment. 

Following  satisfactory  installation  and  acceptance  of  the  equip- 
ment at  the  ADP  site,  it  is  usually  the  responsibility  of  the  site  to 
install  the  applications  programs  and  integrate  as  a functional  com- 
ponent the  procured  equipment  into  the  site  configuration.  This  can 
be  a significant  software  development  effort  in  which  the  site  can  be 
aided  by  one  of  the  centralized  software  support  agencies  within  the 
military  departments  or  on  contract  with  a commercial  software  con- 
sulting firm. 


This  also  includes  the  operating  system  software  to  enable  the 
device  to  function  but  not  the  application  software. 

The  GSA  procurement  role  is  dictated  by  act  of  Congress.  For 
specialized  systems,  DoD  can  obtain  a delegation  of  authority 
from  the  GSA. 

‘Jc’/c'ic 

Usually  that  department  responsible  for  the  site  generating  the 
purchase  requirement. 
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2 . Discussion 

The  important  feature  of  the  above  process  is  the  development  of 
need  by  the  individual  ADP  user.  The  responsibility  for  acquisition 
and  operational  integration  is  divided  between  the  GSA  as  purchasing 
agent  and  the  user's  ADP  site  facility.  This  requirements  and  procure- 
ment process  appears  to  have  been  reasonably  satisfactory.  However, 
with  the  exception  of  a listing  of  major  computer  assets  by  type,  manu- 
facturer, and  location,  the  technical  specifics  of  the  functional  ADP 
systems  are  not  easily  visible  at  higher  management  levels.  The  func- 
tional technical  system  descriptions  usually  are  resident  with  the  par- 
ticular ADP  system  they  describe.  Moreover,  there  is  as  yet  no  uni- 
form or  standard  manner  of  description  although  there  is  momentum 
developing  within  DoD  toward  developing  a standard  set  of  descriptions 
(Refs.  12  and  5). 

Perhaps  of  even  greater  significance  is  that  the  current  require- 
ments process  has  developed  within  the  context  of  stand-alone  computer 
facilities.  Each  facility  generates  an  estimate  of  its  own  work  load 
and  site  processing  capability  in  order  to  determine  inadequacies  in 
task  chroughput  and  thus  generate  a specification  and  justification 
for  an  ADP  hardware  procurement.  There  have  evolved  analytical  and 
simulation  methodologies  along  standard  ADP  task  models*  for  quanti- 
fying requirements  and  numerically  evaluating  candidate  machine  per- 
formance in  satisfying  the  specification  of  need. 

With  varying  degrees  of  success  this  approach  has  been  quanti- 
tatively adequate.  However,  with  the  advent  of  teleprocessing  systems 
containing  off-site  interactive  terminal  capabilities,  the  current 
methodology  has  deficiencies  in  at  least  the  following  areas; 

• The  detailed  interaction  with  communication  trans- 
mission facilities 

• Communications  induced  ADP  tasks  (e.g. , line  control, 
distant  user  protocol) 


These  analyses  are  structured  principally  for  third- generation  on- 
site CPU,  memory,  and  peripheral  interaction. 
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• Interactive  distant  user  tasks 


• Site  architecture  options  (e.g.,  front  ends  versus 
larger  CPU) 

• System  architecture,  on-site  versus  off-site  processing. 

In  fact,  the  problem  is  compounded  by  the  lack  of  even  a definition 
or  standardization  of  what  primary  requirements  data  are  needed  to 
support  an  evaluation  methodology.  There  are  currently  individual 
separate  activities  within  industry  and  government  working  on  this 
problem.  Progress  has  been  made  principally  only  with  centralized 
computer/terminal  systems  with  dedicated  communication  support.  The 
technical  aspects  of  these  issues  are  discussed  further  in  Sections  V 
and  VII. 

B.  ADP  ASSET  INVENTORIES 
1.  Computer  Asset  Lists 

The  GSA,  in  its  role  as  the  U.S.  Government-wide  centralized 
ADP  procurement  agent,  maintains  a (computerized)  listing  of  ADP 
assets  by  manufacturer,  type,  and  location  (Ref.  13).  Each  depart- 
ment and  agency  of  the  DoD  keeps  similar  listings  of  its  own  (Ref.  14). 
The  GSA  data  have  been  aggregated  by  departments  of  the  Government 
into  basic  categories  of  (1)  General  Management  and  Special  Manage- 
ment, (2)  Owned  or  Leased,  (3)  Cost  and  Size,  and  (4)  Single  and 
Multiple  CPU  systems.  Teleprocessing  aspects  and  categorizations 
have  not  as  yet  been  introduced  into  the  GSA-maintained  ADP  data 
base.  Principal  ADP  usage  to  date  has  been  in  stand-alone  computer 
facilities.  However,  IRS  and  Social  Security  are  currently  operating 
teleprocessing  systems.  With  the  growing  utilization  of  teleprocessing 
(including  that  by  GSA  itself),  it  can  be  expected  that  GSA  will  begin 
to  incorporate  teleprocessing  related  data  in  its  ADP  listings . 

The  GSA  data  pertinent  to  Type  II  applications  are  principally 
in  the  General  Management  category.  The  data  from  the  GSA  inventory 
aggregation  are  useful  in  establishing  the  current  level  of  ADP  usage 
in  the  Government.  The  following  figures  are  taken  from  Ref.  13. 
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Figure  16  shows  the  time-dependent  growth  of  Government -owned  com- 
puters versus  leased  computers.  The  overall  number  of  computers  in 
use  has  grown  about  17  percent  between  1968  to  1973  but  the  balance 
between  owned  and  leased  computers  has  changed  from  about  1:1  in 
1968  to  more  than  2:1  in  favor  of  Government  ownership  by  1973.  This 
clearly  indicates  that  in  the  near  future  existing  ADP  facilities 
within  Government  cannot  be  expected  to  be  replaced  at  the  same  rapid 
rate  as  in  the  past  when  most  of  the  assets  were  leased.  Thus,  con- 
siderable emphasis  will  be  placed  on  compatibility  between  new  ADP 
components  or  adjunct  (sub)systems  and  the  existing  facilities. 

Further  categorizing  the  existing  ADP  facilities,  GSA  shows  in 
Fig.  17  the  percentage  in  a given  purchase  price  range  (hence  size) 
as  a total  number  of  owned  systems  and  the  resulting  percentage  of 
the  Government  inventory  commanded  by  that  class  of  computer.  These 
data  demonstrate  the  concentration  of  Government-owned  ADP  facilities 
in  large  computers  although  there  is  a growing  inventory  of  minicom- 
puters. This  further  emphasizes  the  need  to  consider  compatibility 
between  planning  new  systems  and  activities  with  current  facilities. 

In  Tables  9a  and  9b  a usage  breakdown  by  Government  department 
and  CPU  categorization  is  provided.  Table  9a  defines  the  CPU  cate- 
gories. Categories  A and  B have  one  CPU,  Categories  C,  D,  and  E 
have  on  the  average  of  three  CPUs , Category  F has  on  the  average  of 
six  CPUs  and  Categories  G,  H,  and  I have  an  average  of  seven  CPUs. 
Table  9b  shows  that  within  the  Federal  Government,  DoD  is  the  largest 
single  user  of  ADP  followed  by  AEC  and  NASA.  The  categorization  used 
is  not  explicit  as  to  systems  with  teleprocessing  activity  nor  the 
details  of  such  activity.  Of  the  categories  defined  only  Categories 
F through  I would  appear  to  contain  systems  with  potential  teleproces- 
sing function.  Within  the  3460  DoD  listed  systems,  only  22  fall 
within  Categories  F through  I. 

These  data  reconfirm  the  known  fact  that  most  present  ADP  sys- 
tems are  "Stand-Alone."  However,  these  data  do  not  reflect  the 
emerging  trend  of  attaching  remote  terminals  via  dedicated  or  dial-up 
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FIGURE  16.  Computers  in  the  Federal  Government  (General  Management 
Classification)  (Ref.  13) 


NUMBER 

E 


PURCHASE  PRICE  TOTALS 


786 

A 

355 

2,998  SYSTEMS 


w 

S 


_ X $0.27 


A 

$2.42  BILLION 


SYSTEM 

PURCHASE  PRICE 

A.  50,000  OR  LESS 

B.  50,001  - 200,000 

C.  200,001  • 500,000 

D.  500,001  - 1,500,000 

E.  OVER  1,500,000 


FIGURE  17.  Computer  Systems  by  Purchase  Price  Range  (General  Manage- 
ment Classification)  (Ref.  13) 
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total  4,714  845  201  39  132  28  26  29  6,014 


telephone  lines  with  these  "Stand-Alone"  facilities.  This  trend  is 
characterized  by  (and  consistent  with  the  ADP  procurement  process 
discussed  in  Section  IV-A)  the  acquisition  by  each  individual  site* 
of  (1)  communications  "front-end"  processors  compatible  with  the 
existing  facilities  and  operations  context,  and  (2)  the  purchase  or 
lease  of  remote  terminals  compatible  with  the  "front-end"  and  either 
leased  or  dial-up  telephone  circuits. 

DCA , in  a recent  study  (Ref.  1)  for  the  AUTODIN  II  concept,  made 
a comprehensive  survey  of  existing  DoD  facilities  in  order  to  develop 
a traffic  flow  model  for  studying  alternative  design  concepts  and 
parameters.  The  data  were  collected  with  the  fundamental  objective 
that  as  large  a number  of  candidate  subscriber  ADP  facilities  as  pos- 
sible be  accommodated  within  an  AUTODIN  II  design.  Thus,  the  existing 
facilities  were  not  examined  for  any  systematic  substructure.  Such  an 
effort  would  have  been  substantial  and  beyond  the  needs  of  developing 
an  initial  traffic  model  for  the  AUTODIN  II  objective.  (However,  the 
facilities  were  aggregated  by  geographical  location,  as  would  be  re- 
quired for  a network  topology. ) 

Table  10  is  taken  from  Ref.  1 showing  for  each  DoD  element  the 
projected  1978  distribution  by  CPU  size  and  basing  of  computers  with 
potential  data  communication  needs  which  DoD  elements  identified  as 
being  candidates  for  common-user  service.  These  facilities  are  prin- 
cipally Type  II  with  the  exception  of  the  WWMCCS  computers  which  are 
a mix  of  Type  I and  Type  II  and  are  shown  for  comparative  purposes. 
These  data  show  the  dominant  Air  Force  position  in  ADP  systems. 


>Y 

Many  stand-alone  sites  are  administered  by  a command,  military  de- 
partment or  agency  in  aggregate  form  (e.g.,  Air  Force  Base  Ops 
facilities).  Thus,  teleprocessing  can  be  here  viewed  as  individual 
purchase  in  bulk  quantities. 
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TABLE  10.  1978  PROJECTION  OF  DoD  MAJOR  COMPUTER  ASSETS 

BY  DEPARTMENT  AND  SIZE  (Ref.  1) 


DOD  ELEMENT 

AND  LOCATION: 

CONUS/OVERSEAS 

NUMBER  COMPUTERS* 

WWMCCS (TYPE  X) 

DOD  AGENCIES 

AIR  FORCE 

NAVY/MARINES 

ARMY 

Small 

0-0. S MB 

7/2 

0/0 

463/78 

311/19 

169/64 

Medium 

0. 5-3.0  MB 

11/4 

11/0 

225/50 

104/15 

63/13 

Large 
>3.0  MB 

36/4 

12/0 

57/0 

23/0 

40/2 

TOTAL  NO.  COMPUTERS 

54/10 

23/0 

745/128 

438/34 

272/89 

NUMBER  BASES** 

Small 

0-1.5  MB 

12/6 

6/0 

95/38 

23/11 

105/15 

Medium 

1.5-3  MB 

3/0 

4/0 

14/0 

s/o 

9/0 

Large 
>3  MB 

2/0 

0/0 

7/0 

3/0 

1/0 

TOTAL  NO.  BASES 

17/6 

10/0 

116/38 

31/11 

115/15 

*Computer  size  is  categorized  by  size  in  megabits  (8  bits  - 1 byte) 
of  CPU  core  memory. 

Base  size  is  categorized  by  adding  core  memory  of  all  CPUs  resident 
on  base. 


From  GSA  1973  data,  it  is  apparent  that  DoD  accounts  for  approxi- 
mately 70  percent  of  the  computer  assets  in  the  Federal  Government. 

Of  the  DoD  computers,  the  Air  Force /Navy /Army  split  39/30/26  percent 
with  5 percent  going  to  DoD  agencies.  From  DCA  1978  projections  of 
computers  with  potential  for  data  communication  needs,  the  Air  Force/ 
Navy/Army  split  is  48/26/20  percent  plus  4 percent  for  WWMCCS  and 
2 percent  for  DoD  agencies.  However,  in  terms  of  the  number  of  sites 
with  computers , the  Army  approximately  equals  the  Air  Force  with  an 
Air  Force /Navy /Army  split  of  44/12/36  percent  and  6 percent  for  WWMCCS 
and  2 percent  for  DoD  agencies. 
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Comparison  of  GSR  1973  data  (Ref.  13)  and  DCA  1978  projections 
(Ref.  1)  would  indicate  that  within  DoD,  the  Air  Force  has  the  most 
rapidly  developing  need  for  teleprocessing  activities.  Further  com- 
parison shows  that  the  Navy  is  the  second  most  rapidly  advancing 
potential  user  of  computer  teleprocessing  but  has,  by  a wide  margin, 
the  fewest  geographically  distributed  sites.  The  Armv,  which  appears 
to  have  the  more  conservative  approach  to  teleprocessing,  has  almost 
as  wide  a geographic  distribution  in  basing  as  the  Air  Force. 

From  these  data  one  could  expect  the  earliest  need  for  data  net- 
work support  with  significant  geographic  coverage  to  teleprocessing 
to  develop  within  Air  Force  related  ADP  activities.  Army  network 
needs,  perhaps  latest  in  time  urgency,  can  require  a network  geographic 
distribution  as  extensive  as  the  Air  Force.  The  Navy  network  needs 
probably  can  be  more  concentrated  into  fewer  long-haul  trunks. 

2.  Functional  System  Inventories 

Within  the  Headquarters  element  of  each  of  the  military  Services 
and  agencies  of  DoD,  there  is  an  ADP-related  section  for  monitoring 
and  overseeing  ADP  activities  of  the  respective  Service  or  agency. 

These  offices  help  collect  and  maintain  the  DoD  and  GSA  ADP  data  base 
described  in  the  previous  section.  In  addition,  listings  are  made  of 
ADP  functional  systems.  A typical  functional  system  is  composed  of 
standardized  applications  program  software  run  on  principally  stand- 
alone standardized  computers  distributed  throughout  an  organization 
(e.g.,  materiel  command)  plus  the  collection  of  periodic  data  inputs 
and  the  generation  and  distribution  of  reports.  An  example  of  such 
a listing  is  shown  in  Table  11  provided  by  the  Management  Information 
Systems  Office  of  the  Army  Chief  of  Staff.  Here  is  shown  in  synoptic 
form  the  functional  system,  SPEEDEX,  its  function,  applications  pro- 
grams, and  the  type  and  location  of  the  ADP  iacilities.  Also  indi- 
cated is  the  presence  of  some  remote  terminals  in  the  system. 

The  various  responsible  DoD  offices  maintain  similar  listings 
of  functional  systems  in  a format  most  convenient  to  their  needs. 

There  is  as  yet  no  DoD-wide  standard  way  of  listing  the  functional 
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TABLE  11.  ARMY  MANAGEMENT  INFORMATION  SYSTEM- -SYSTEMS  STATUS  REPORT 
(Courtesy  of  Management  Information  Systems  Office,  Army  Chief  of  Staff) 


systems.  A preliminary  listing  was  reported  in  Ref.  15.  Scheduled 
for  publication  in  November  1974  is  a listing  of  ADP  systems  in  use 
by  the  DoD.  This  is  a major  effort  undertaken  by  the  DoD  Logistic 
Systems  Policy  Committee,  ASD(ILL),  LSPC  Task  3-70  (Ref.  12).  This 
inventory,  however,  will  not  directly  assess  the  teleprocessing 
features  of  the  identified  DoD  systems.  As  part  of  the  DoD  Internet 
Study  tasked  by  DTACCS  (Ref.  5,  Appendix  F)  a listing  of  operating 
and  proposed  DoD  ADP  systems  and  their  characteristics  has  been  pre- 
pared and  is  currently  maintained  by  the  DCA  at  its  Engineering  Sup- 
port Center,  Reston,  Virginia. 

3.  Communications 

To  the  best  knowledge  of  the  authors  of  this  report  and  with  the 
exception  of  AUTODIN  I*,  no  aggregated  communications  utilization 
data  for  circuits  and  terminals  specifically  associated  with  supporting 
current  teleprocessing  activities  within  DoD  are  available.  Communi- 
cation data  do  exist  as  a component  of  each  specific  system  descrip- 
tion. Consequently,  such  data  are  in  considerably  fragmented  form. 

The  communications  elements  are  being  studied  and  analyzed  as  a part 
of  teleprocessing  systems  studies.  Reference  5 contains  the  most 
current  estimates  of  current  need  and  projected  flow. 

C.  TELEPROCESSING  SYSTEMS 

The  systems -related  requirements  activities  can  be  categorized 
as  follows* 

1.  Teleprocessing  upgrade  to  existing  ADP  facilities  (Ref.  16) 

2.  New  teleprocessing  systems  including  new  ADP  facilities 
(Ref.  2) 

3.  Common-user  network  (Refs.  5,  9) 


AUTODIN  I speed  of  service  or  mode  of  operation  is  generally  con- 
sidered to  be  inadequate  for  the  technical  requirements  of  future 
interactive  or  transactional  teleprocessing  systems.  Furthermore, 
additional  heavy  growth  in  computer-associated  communications  can 
place  too  heavy  a traffic  burden  on  AUTODIN  I capacity. 
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Almost  all  presently  operating  systems  are  in  category  1,  that 
is  to  say,  stand-alone  ADP  sites  which  have  added  remote  terminals 
to  upgrade  with  some  teleprocessing  capabilities.  Systems  of  cate- 
gory 1 add  terminals  at  known  sites*  with  a need  to  communicate  with 
an  existing  specified  ADP  facility.  The  requirements  for  such  spe- 
cific systems  tend  to  be  well  delineated  as  to  terminal  configurations  , 
line  speeds,  traffic  volume,  response  time,  etc.  The  requirements 
usually  lead  to  specific  technical  specifications  of  terminals,  modems, 
transmission  lines,  and  ADP  site  modifications.  This  is  illustrated 
in  Fig.  18  taken  from  the  proposed  interim  MAC  Information  Management 
System  (MACIMS)  (Ref.  16). 

An  example  of  category  2 is  the  Computer  Network  concept  of  the 
SADPR-85  study  discussed  in  Section  III.  Here  requirements  generation 
becomes  more  complex.  Both  ADP  sites , as  well  as  terminal  locations 
and  sizings,  must  be  made  in  addition  to  choosing  a communications 
topology  and  capacity.  Based  on  current  and  projected  ADP- related 
tasks , a model  is  generated  relating  computer  loading  with  terminal 
transaction  activity  to  component  system  performance  factors.  From 
this  computer  and  terminal  capacity  is  projected,  and  traffic  flow 
requirements**  between  computers  and  terminals  are  estimated.  This, 
then,  becomes  an  input  to  a communications  network  design  to  layout 
line  connectivity  and  capacity. 

An  example  of  category  3 is  the  DCA  AUTODIN  II  concept  (Ref.  1 ) 
discussed  in  Section  III.  There  the  principal  requirements  focus  on 


traffic  flow  necessary  to  design  and  size  a common-user  switched 
data  communications  network.  The  communications  traffic  flow  was 
modeled  independently  of  specific  AD?  tasks.  Data  were  collected  on 
computer  size  and  location  as  well  as  projected  terminal  types  and 

D 

* 

Within  the  command  or  mission  responsibility  of  the  parent  ADP 
facility. 

A complex  quantity  including  a geographic  matrix,  daily  flow,  peak 
hour  flow,  response  time  (interactive),  tolerable  error  rate,  etc. 
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locations.  Terminal  node  flow  capacity  was  derived  from  question- 


naires submitted  to  various  DoD  elements  which  solicited  number, 
location,  type  of  terminals,  and  type  of  service  envisioned.  With 
the  same  solicitation  together  with  available  computer  inventory 
lists,  CPU  location  and  core  memory  size  were  determined.  Flow 
capacity  for  computer  nodes  was  derived  from  a model  relating  CPU 
core  memory  capacity  with  data  transaction  activity.  This,  then, 
was  used  to  determine  data  node  (source /sink)  locations  and  node 
flow  capacity.  With  the  flow  data  in  this  form  the  backbone  packet- 
switching network  design  was  studied.  The  justification  for  this 
approach  (aside  from  the  limited  resources  and  data  available  to  the 
study  effort)  resides  in  the  theoretical  results  derived  from  ARPANET 
studies  (Ref.  17).  It  was  shown  that  in  a large  packet- switched  net- 
work, the  system  design  was  dominated  by  location  of  data  nodes,  the 
total  aggregated  flow  in  the  network  as  a whole,  and  the  flow  in/out 
of  the  largest  data  nodes.  Due  to  the  routing  strategies  used  in 
ARPANET  packet  switching,  the  network  design  is  relatively  insensi- 
tive to  the  detailed  structure  of  the  flow  between  all  paired  nodes. 

In  addition  to  the  backbone  portion  of  the  network,  the  data 
collected  in  Ref.  9 also  provide  a base  for  analyzing  the  require- 
ments for  access  lines  to  the  backbone  network.  The  access  line 
requirement  is  intimately  related  to  backbone  topology  as  the  number 
and  length  of  access  lines  needed  depend  on  the  location  of  the  ac- 
cess points  to  the  backbone  network.  The  overall  network  topology 
and  associated  component  capacity  requirements  (lines  and  switches) 
form  a delicate  interplay  between  the  backbone  and  access  line 
portions.  Sophisticated  graph  theoretic  techniques  must  be  utilized 
with  computer-aided  design  using  an  interactive  set  of  algorithms* 
to  seek  an  optimum  overall  network  design. 


This  process  has  been  referred  to  as  heuristic  programming. 
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As  part  of  the  DTACCS  Internet  Study*  (Ref.  5)  a reexamination 
of  the  DoD  candidate  teleprocessing  systems  has  been  conducted  and 
will  continue.  One  of  the  objectives  is  to  refine  the  technical 
requirements  of  the  more  immediate  candidate  subscribers  to  a common- 
user  switched  data  network.  Additional  data  are  also  provided  as  to 
the  other  proposed  teleprocessing  systems  and  their  time  frame.  This 
provides  for  the  first  time  in  DoD  a common  frame  of  reference  for 
preparing  teleprocessing  system  description^fcid  requirements.  With- 
out such  a requirements  overview,  it  is  veri^^gf ficult  to ^ssess  the 
present  status  and  projected  teleprocessing ^eeds  or  to  mike  judgments 
as  to  priority  of  need. 

D.  SUMMARY 

In  this  section  a review  of  the  type  of  data  available  within 
DoD  as  to  ADP  assets  and  systems  and  the  relationship  to  formulating 
teleprocessing  requirements  was  presented.  The  principal  ADP  utili- 
zation data  collected  to  date  in  aggregated  form  relate  to  inventory 
lists  of  computer  hardware  and  location  for  primarily  stand-alone 
facilities . 

The  present  teleprocessing  requirements  formulation  is  done  on 
a system-by-system  basis,  a reasonable  process  compatible  with  up- 
grading present  systems  but  inadequate  for  any  overview  of  aggregated 
teleprocessing  requirements.  The  studies  in  Refs.  1,  2,  and  3 exhibit 
by  example  some  of  the  factors  required  in  developing  and  aggregating 
teleprocessing  requirements. 

Functional  ADP  systems  data  have  been  collected  and  aggregated 
by  two  studies  sponsored  by  OASD(ISL)  (Refs.  18  and  19).  Reference  5 


Reference  5 only  became  available  in  draft  form  during  the  final 
preparation  phase  of  this  study.  Consequently,  no  time  was  avail- 
able to  digest  the  results  and  incorporate  them  here.  The  inter- 
ested reader  is  strongly  urged  to  examine  Ref.  5. 


provides  development  of  Functional  System  Data  in  a form  relevant  for 
formulating  teleprocessing  requirements.  These  data  have  been  collected 
as  an  interim  ad  hoc  committee  activity.  There  currently  is  no  one 
element  within  DoD  or  more  specifically  OSD  charged  with  developing 
and  maintaining  a current  and  more  comprehensive  ADP  utilization 
data  base,  especially  to  include  teleprocessing-related  data.  Tele- 
processing-oriented requirements  data  are  needed  in  order  to  address 
the  following  issues: 

• System  architecture  (centralized  versus  decentralized 
processing) 

• Individual  ADP  site  configuration 

• Communications- induced  ADP  tasks 

• ADP- induced  communications  capacity  and  transmission 

i configuration. 

It  is  very  important  to  establish  within  DoD  a requirements  formula- 
tion function  to  provide  a comprehensive  view  of  ADP  needs  including 
data  communications. 

h 

I Computer  inventory  listings  and  their  base  site  distribution 

indicate  that  the  earliest  needs  for  Type  II  teleprocessing  with  the 
most  geographically  extensive  communications  requirements  will  most 
likely  develop  within  the  Air  Force.  The  Navy  data  communications 
needs  to  support  Type  II  teleprocessing,  although  next  most  rapidly 
developing,  should  be  more  geographically  concentrated.  The  Army, 
with  perhaps  the  most  conservative  approach,  nonetheless  will  even- 
tually need  data  communications  as  geographically  extensive  as  those 
of  the  Air  Force. 


V. 


DESIGN  AND  ARCHITECTURAL  CONSIDERATIONS 


Architecture  and  design  considerations  for  teleprocessing  systems 
are  characterized  by  dimensional  complexity  and  analytical  difficulty. 
In  addition  to  the  technological  design  problems , there  is  the  cost 
sensitivity  to  complex  schedules  of  transmission  tariffs  and  equip- 
ment charges.  In  projecting  future  availability  of  equipment  and 
cost  trends,  one  must  be  aware  of  the  intangible  business  interests 
of  the  suppliers  of  equipment  and  services  with  regard  to  competitive 
market  factors,  continuity  of  product  lines,  and  customer  capture. 

The  object  of  this  section  is  to  summarize  the  elements  of  design 
and  analytical  methods  currently  in  use.  This  then  provides  an  oppor- 
tunity to  discuss  areas  of  insufficient  technical  understanding  and 
gaps  in  methodology. 

Present  design  methods  have  evolved  in  the  context  of  cost- 
effective  utilization  of  the  current  telephony  plant  to  support  cen- 
tralized third-generation  computer  centers.  Design  techniques  have 
focused  on  providing  dedicated  teleprocessing  systems  utilizing  com- 
munications as  a component  subsystem  of  the  overall  ADP  system.  Such 
systems  have  been  principally  utilized  by  corporate  ADP  activities  on 
the  one  hand  and  commercial  service  bureau  or  time-sharing  systems  on 
the  other.  In  the  latter  case,  a data  network  is  employed  to  reduce 
long-distance  toll  charges  to  the  general  public  subscribers.  The 
network  portion  of  the  overall  teleprocessing  system  is  designed  and 
operated  in  support  of  a vertically  integrated  ADP  system.  The  inter- 
face with  the  subscriber  is  at  the  nearest  node  or  point  of  access 
to  the  network.  The  network  is  effectively  an  extension  of  the  com- 
puter center(s). 
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With  the  advent  of  the  ARPANET*,  design  methodologies  have  begun 
to  evolve  wherein  common-user  data  communication  factors  are  addressed 
in  their  own  right.  These  methodologies , however,  initially  tended  to 
be  rather  tightly  coupled  to  the  ARPANET  specific  concepts  of  operation 
(standard  interface  and  network  protocol,  distributed  topology,  adap- 
tive routing,  and  specific  division  of  network  responsibilities,  vis- 
a-vis  subscriber,  e.g.,  error  control).  Only  recently  has  the  devel- 
opment of  these  design  techniques  been  broadening  into  more  general  tools. 

A.  DESIGN  TOPOLOGY  AND  ANALYSIS 
1.  Topological  Types 

There  are  two  very  different  classes  of  network  topologies  (i.e. , 
the  arrangement  of  nodal  points  and  their  line  interconnections).  One 
is  the  Star  topology  as  shown  in  Fig.  19  representing  the  proposed 
initial  phase  of  the  MACIMS  network  (Ref.  16).  A generalization  of 
the  Star  is  the  Tree  topology  which  is  shown  in  Fig.  20a . Figure  20b 
shows  a loop  variation  of  the  Star.  A key  feature  of  the  Star  or  Tree 
topology  is  the  focus  on  a centralized  computational  center  whose  com- 
munications fan  out  to  its  remote  users. 


OVERSEAS  BASES 


It  is  worth  noting  here  that  the  first  operational  and  largest 
operating  network  using  packet  data  transmission  is  SITA  (Ref. 
20),  supporting  a common  European  airline  reservation  system. 
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The  other  type  of  topology  is  the  distributed  network  for  which 
an  idealized  type  is  the  n-node  m-connected  graph  shown  below,  wherein 
there  are  m connections  between  each  of  n nodes. 


The  idealized  type  of  network  connections  in  distributed  systems  are 
of  little  direct  practical  interest.  Most  distributed  networks  are 
more  complex  variations.  The  best  known  example  of  a distributed 
network  is  the  ARPANET  whose  evolution  through  time  (up  to  1972)  is 
shown  in  Fig.  21.  The  distributed  network  usually  provides  greater 
communications  path  redundancy  [hence  enhanced  reliability  (Ref. 

21)],  but  does  not  economically  support  a centralized  teleprocessing 
system. 

Several  operating  teleprocessing  systems  to  date  have  evolved 
hierarchical  mixes  of  centralized  Star  (Tree)  subnetworks  intercon- 
nected with  a distributed  backbone  network.  Examples  of  these  are 
shown  in  Figs.  22,  23,  and  24  representing  the  network  topologies 
of  CYBERNET,  TYMNET,  and  INFONET,  respectively.  Here  each  Star  sub- 
net evolved  in  support  of  its  centralized  (regional)  ADP  center. 
However,  the  regional  ADP  centers  are  interconnected  in  a distributed 
fashion  to  provide  reliable  backup  together  with  load  and  resource 
sharing  between  centers . 

The  type  of  network  topology  and  hierarchical  architecture  uti- 
lized in  the  design  is  quite  important.  Analytical  and  design  opti- 
mization techniques  depend  on  the  class  of  topology  postulated.  Broad 
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FIGURE  21  . The  Evolution  of  the  ARPANET  (Ref.  22) 


FIGURE  22.  CYBERNET  Service  (Courtesy  of  Control  Data  Corporation) 


FIGURE  23.  TYMNET  Map  (Ref.  23) 


FIGURE  24.  INFONET  Communications  Networks  (Ref.  9-3) 
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topological  characteristics  must  be  chosen  or  hypothesized  prior  to 
the  analysis.  Guidance  in  this  choice  must  derive  from  judgment  de- 
pending on  the  type  of  operation,  ADP  task,  and  choice  of  processor 
locations.  Additionally,  consideration  of  system  evolution  is  impor- 
tant in  choice  of  network  topology  desired. 

2.  Design  and  Analysis 

The  design  and  analysis  of  teleprocessing  systems  have  usually 
been  decomposed  into  three  major  areas  of  investigation:  The  user 
(or  terminal)  characteristics  and  needs;  the  ADP  site(s)  configu- 
ration, workload,  and  performance;  and  the  communications  network. 
This  is  depicted  in  part  in  Fig.  25  which  attempts  to  show  the  types 
of  considerations  and  data  inputs  for  each  area  and  the  high  inter- 
dependence between  areas.  Each  area  is  a major  subarea  of  analysis. 
The  tight  coupling  of  users  and  ADP  processing  sites  is  obvious. 

Conventional  design  practice  treats  the  communications  as  a 
purchasable  component  of  the  system  and  attempts  to  minimize  the 
component  cost.  In  most  design  practices,  the  "terminal"  has  been 
treated  as  equivalent  to  a distant  peripheral  to  a host  computer  at 
a given  location.  Recently,  analytical  interest  has  been  develop- 
ing in  studying  optimum  teleprocessing  configurations  for  satisfy- 
ing the  "user  demand"  as  opposed  to  extending  the  supply  of  computer 
services  to  remote  users.  Here  the  location  and  "size"  of  ADP  sites 
are  varied  to  meet  user  requirements  economically.  The  communica- 
tions network  then  develops  as  a cost  factor  in  overall  design. 

The  complexity  of  analysis  is  self-evident  from  Fig.  25  with 
heavy  dependence  on  data  that  are  quite  changeable  or  as  yet  unknown 
(costs,  tariffs,  market  demand)  and  rapidly  changing  technology 
(CPU,  memories,  terminals,  data  transmission,  and  switching).  In 
many  cases,  the  analytical  tools  are  yet  to  be  developed.  There  is 
generally  a heavy  dependence  on  simulation  and/or  model  simplifica- 
tion. An  example  study  effort  is  provided  in  Refs.  3 and  24 . 
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75  8 FIGURE  25.  Interrelation  of  Teleprocessing  System  Design  Areas 


A further  breakdown  of  the  design  process  for  the  communications 
network  is  shown  in  Fig.  26.  Given  a desired  type  of  network  topology, 
traffic  flow,  specification  of  statistical  parameters,  and  desired  com- 
munication response  time,  a least-cost  network  is  developed  depending 
upon  offered  transmission  and  switching  services  and  their  tariffs. 

This  network  layout  is  developed  using  iterative  techniques  from  flow 
graph  theory  (Ref.  25).  Network  sensitivity  to  variations  in  traffic 
and  costs  can  also  be  examined  (see,  for  example,  Ref.  3).  Having  an 
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initial  theoretical  network  layout  of  nodal  locations,*  line  routes  and 
their  respective  capacities  (nodal  throughput  and  line  speed  or  band- 
width) provide  cost  estimates  that  can  be  interacted  with  the  computer/ 
terminal  design  which  results  in  reevaluating  initial  assumptions  and 
guidelines  and  then  reiterating  the  design  process. 
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FIGURE  26.  Teleprocessing  Communication  Network  Design  Process 


ADP  sites,  access  points,  concentration  and/or  switch  points. 
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With  an  initial  network  concept,  topology,  and  estimated  capacity 
requirements,  detailed  analysis  is  then  directed  at  equipment  design 
and  development,  especially  at  network  nodes  to  provide  the  necessary 
network  functions.  The  logic  design  and  sizing  of  nodal  processors 
and  memories  for  concentrators , switches , and  front  ends  together  with 
developing  routing  algorithms,  access  standards,  network  control,  and 
associated  system  software  (Ref.  26)  are  some  of  the  major  nodal  de- 
sign problems.  Here,  again,  reiteration  with  the  network  topology  and 
sizing  is  required.  In  addition  to  cost  impact,  specific  design  de- 
velopments in  network  nodal  and  access  features  also  have  strong  in- 
teraction with  the  ADP  site  and  terminal  equipment  and  usage  (Refs. 

26,  27,  28). 

The  familiar  problem  of  ADP  site  configuration  and  management 
analysis  is  conceptually  analogous  to  the  problem  in  designing  the 
communications  network.  Here  the  architecture,  sizing,  allocation, 
and  control  of  site  assets  (CPUs,  memories,  I/O  devices,  etc.)  are 
of  concern.  This  problem  area,  predating  that  of  the  communications 
network,  certainly  has  received  the  preponderance  of  effort  in  the 
past  and  has  a more  developed  methodology  than  network  design.  Even 
so,  the  analytical  tools  do  not  appear  to  be  in  a sufficient  state  of 
advancement  to  adequately  answer  many  questions  of  practical  importance , 
e.g. , predicted  versus  realized  performance.  Inadequate  design  methods 
usually  result  in  the  acquisition  of  oversized  or  underutilized  com- 
ponents to  achieve  a margin  of  safety.  However,  unexpected  processing 
choke  points  often  develop.  The  latter  cause  the  more  significant 
economic  loss.  It  appears  that  the  design  inadequacies  are  due  to  an 
inability  to  predict  accurately  the  performance  of  the  interdependent 
hardware/software  system. 

The  design  methodologies  used  for  both  ADP  site  configuration  and 
communication  networking  are  based  upon  the  mathematical  tools  of 
queueing  theory  and  flow  graph  theory,  as  well  as  relying  heavily  on 
computer  simulation  techniques.  However,  the  respective  problem  con- 
straints and  design  objectives  desired  between  site  configuration  and 
networking  are  sufficiently  different  to  have  caused  development  of 


119 


differing  specializations  of  the  analytical  methods.  For  example,  com- 
munication constraints  on  data  speed  and  delay  are  of  less  concern  in 
analyzing  ADP  site  configuration.  On  the  other  hand,  storing  and  ma- 
nipulating large  arrays  of  data  or  interleaving' a multiplicity  of  proc- 
essing tasks  have  been  of  lesser  concern  to  the  data  communications 
design. 

There  is  developing  a strong  need  to  bring  together  these  two 
areas  of  theoretical  endeavor.  This  follows  from  the  coupling  between 
(a)  network  design  and  load  and  (b)  ADP  site  configuration  and  tasking. 
Furthermore,  implementing  communication  network  nodal  functions,  such 
as  access  control,  switching  or  message  routing,  concentrating,  etc., 
will  depend  on  utilizing  AD?  technology,  i.e.,  the  node  is  itself  an 
ADP  site  in  miniature  with  specific  processing  tasks.  Additionally, 
nodal  activities  may  in  part  be  collocated  with  a processing  site  and 
be  included  within  the  site  configuration  planning. 

In  addition  to  the  problems  in  the  design  of  teleprocessing  sys- 
tems, there  are  many  problems  of  great  practical  interest  and  theoret- 
ical challenge  in  how  a teleprocessing  system  is  used.  One  of  the 
main  motivations  for  developing  the  ARPANET  was  to  address  such  prob- 
lems. Illustrative  objectives  include; 

• Manipulating  geographically  distributed  data  bases 

• Utilization  or  sharing  of  ADP  assets  (hardware  and/or 
software)  between  sites 

• Distributed  processing. 

These  have  led,  for  example,  to  studies  in  computer  language  transla- 
tion, data  structures  and  architecture,  interprocess  protocols,  sys- 
tems control,  and  privacy. 

Interesting  problems  exist  in  cost  optimization  of  an  existing 
teleprocessing  system.  For  example,  in  Ref.  29,  the  problem  is  ad- 
dressed of  least-cost  assignment  of  residence  of  a user's  programs 
at  different  sites  where  program  length  and  utilization  factors  to- 
gether with  storage  and  transmission  costs  are  given.  This  leads  to 
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a linear  integer  programming  solution  whose  dimensions  grow  exponentially 
fast  with  the  number  of  programs  and  choice  of  available  resident  sites. 

B.  SYSTEM  SHARING 

1.  Sharing  Elements 

The  previous  section  outlined  the  analytical  features  used  in 
designing  a teleprocessing  system  without  addressing  issues  associ- 
ated with  intersystem  operation  or  sharing.  The  objective  here  is  to 
focus  on  some  of  the  factors  introduced  by  sharing.  Design  factors 
in  the  sharing  of  system  communication  assets  take  on  special  signifi- 
cance in  regard  to  the  major  issues  that  relate  to  the  organization, 
implementation,  and  use  of  common-user  switched  data  networks  as  op- 
posed to  providing  dedicated  communication  support  to  teleprocessing 
systems.  Technical  issues  that  relate  to  sharing  arise  within  as 
well  as  between  systems.  Any  computer  site  with  ADP  "time- sharing" 
capabilities  is  shared  as  a dedicated  communication  network  is  shared 
by  the  remote  terminals  accessing  the  computer.  It  is  not  always 
clear  as  to  where  problems  of  intrasystem  sharing  leave  off  and  inter- 
system  sharing  begins.  Much  depends  on  the  specification  of  system 
boundaries  and  responsibilities.  The  issues  of  separation  and  assign- 
ment of  system  responsibility  are  themselves  a problem  area. 

There  are  three  subsystem  components  in  teleprocessing  that  can 
be  shared: 

1.  Terminals 

2.  Communication  facilities  by  different  computer  systems 
and  associated  terminals 

3.  Computer  facilities:  hardware,  programs,  data  bases. 

The  sharing  of  computer  facilities,  hardware,  software,  and  data  bases 
is  a major  activity  in  computer  science.  Sharing  of  ADP  resources 
represents  the  most  significant  potential  for  obtaining  the  greatest 
reduction  in  overall  ADP  costs  through  appropriate  aggregation  of  ADP 
tasks,  organization  of  function,  and  location  of  computer  facilities 
relative  to  as  broad  a shared  user  base  as  can  be  satisfactorily  achieved 
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In  what  follows,  discussion  is  focused  on  sharing  communications 
for  interconnecting  computers  and  terminals . Whatever  potential  econ- 
omies can  be  achieved  through  the  aggregation  and/or  sharing  of  ADP 
functions , such  economies  cannot  be  realized  without  a communications 
network.  The  economies  that  can  be  realized  through  sharing  communi- 
cation facilities,  though  significant,  should  not  be  allowed  to  in- 
hibit realizing  the  savings  achievable  in  computer  (including  O&M) 
costs.  Discussion  here  is  directed  principally  to  sharing  the  communi- 
cations network  components  because  the  issues  appear  to  be  more  de- 
veloped. 

Many  have  assumed  implicitly  that  a subscriber-oriented,  common- 
user,  switched  data  communications  network  represents  an  ultimate  in 
shared  communications.  This  follows  naturally  from  the  example  set  by 
and  economies  realized  from  the  common-user  telephony  plant.  For  data 
communications,  it  remains  to  be  demonstrated  that  such  an  "ultimate" 
will  prove  both  technically  adequate  and  economically  attractive.  Human 
subscribers  of  the  common-user  telephony  plant  employ  standard  equipment 
(handset,  auditory  and  vocal  apparatus)  together  with  a standard  mix  of 
protocols  and  adaptive  capabilities  (language,  cultural  context,  inquiry/ 
analysis)  not  yet  achieved  with  data  processing  systems. 

2.  Sharing  and  Switching 

In  discussing  the  design  issues  for  sharing  communication  facili- 
ties, it  is  useful  to  stipulate  which  communication  components  are  being 
shared,  and  tneir  structural  relationships.  It  is  possible  to  share 
facilities  at  different  levels  with  different  communication  functions. 

In  CONUS,  almost  all*  dedicated  teleprocessing  systems  "share"  the 
transmission  facilities  of  the  Common  Carriers  (principally  the  Bell 
System).  Presumably,  even  if  DoD  teleprocessing  systems  were  to  de- 
velop in  a proliferated  manner,  they  would  still  share  the  DCS  trans- 
mission facilities.  Consequently,  the  structure  of  the  shared  communi- 
cation elements  will  have  large  bearing  on  required  circuit  routes  and 
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capacity,  nodal  locations,  and  switching.  Of  even  greater  ultimate 
importance  is  sharing  ADP  functions  and  terminal  capabilities. 

Within  communications  assets,  the  following  elements  can  be 
shared  in  a number  of  arrangements; 

• Local  access--loops  or  distribution  lines 

• Multiplexers,  concentrators 

• Long-haul  transmission. 

The  span  of  sharing  across  these  elements  together  with  desired  de- 
gree of  site  interconnectivity  then  lead  to  requirements  for  the 
fourth  element: 

• Switches. 

For  example,  it  is  possible  to  conceive  of  a shared  communication 
system  in  which  there  is  no  switching  within  the  communications  net- 
work. Subscriber  sites  specify  in  advance  all  other  sites  to  whom 
they  wish  to  connect  within  their  own  system(s).  Any  switching  is 
done  at  the  subscriber's  site  and  "new"  messages  reintroduced  to  the 
communications  plant.  Such  a system  can  be  implemented  with  dedicated 
trunks  and  multiplexers  which  are  (re)connected  at  the  subscriber's 
order.  Further,  certain  "simple"  type  circuit  switches  could  be 
implemented  to  facilitate  network  control,  circuit  restoration,  and 
quicker  response  to  new  subscriber  connectivity  orders.  This  system 
description  is  obviously  that  of  the  present  Common  Carrier  facilities 
as  it  provides  shared  service  to  dedicated  teleprocessing  systems. 

The  introduction  of  concentrators  that  provide  dynamic  time 
sharing  of  the  long-haul  trunks  realizes  the  principal  potential  for 
cost  reduction  in  long-haul  data  transmission  costs  over  fixed  routes. 
In  this  context,  the  term  switching  is  somewhat  ambiguous.  The  narrow 
meaning  refers  to  the  ability  of  any  system  subscriber  to  call  any 
other  subscriber  on  demand.  However,  in  a broader  sense,  there  is 
switching  involved  in  the  long-haul  concentrators.  The  implied  con- 
cept is  to  prestore  in  the  concentrators  all  of  the  preordered  paired 
subscriber  connections  allowed.  In  this  fashion,  the  paired  users 
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could  dynamically  use  the  trunks  as  needed,  but  on-call  connections 
could  not  be  made.  Concentrators  operating  in  this  mode  achieve  the 
economic  advantages  in  number  of  trunk  lines  needed  as  well  as  the 
dynamic  sharing  of  trunk  capacity.  [In  fact,  switches  were  introduced 
in  the  telephony  plant  for  the  purpose  of  "concentrating"  subscribers' 
use  of  circuits.  It  was  taken  as  a matter  of  course  that  any  sub- 
scriber (human)  should  be  able  to  connect  to  any  other  subscriber 
(human).  For  current  teleprocessing  system,  this  assumption  may  not 
be  valid.]  Thus,  if  cost  reductions  for  long-haul  communications  are 
achieved  through  either  lower  tariff  rates  and/or  dynamic  time  sharing 
of  the  line  capacity,  the  principal  advantages  to  sharing  long-haul 
transmission  facilities  will  have  been  achieved-  The  need  to  share 
communication  access  lines,  terminals,  and,  to  a lesser  degree,  on-call 
interconnection  of  ADP  systems  would  appear  to  be  the  principal  fac- 
tors for  developing  dynamic  network  switching. 

Communication  facilities  can  be  shared  in  at  least  the  following 

ways: 

a.  Bilateral  (or  multilateral)  agreements  between  parties 
with  congruent  transmission  routes 

b.  Aggregates  of  users  agreeing  to  pool  communications 
with  minimal  switching  capability  as  in  the  example 
quoted  above 

c.  Common-user  switched  system 

d.  A mixture  of  the  above. 

Small  systems  will  be  motivated  toward  sharing  communication  facili- 
ties, especially  costly  long-haul  circuits.  Large  systems,  for  which 
communications  are  a smaller  percentage  of  cost  and  who  must  emphasize 
the  integrity  and  control  of  their  own  system,  will  be  motivated  to 
acquire  "dedicated"  communication,  i.e.,  one  whose  utilization  and 
control  of  capacity  is  under  their  control.  This  provides  an  impor- 
tant variation  on  (d)  above,  namely 

e.  Piggyback  communications  service  provided  by  a 
"large"  system  to  a smaller  system. 


The  level  and  arrangement  of  desired  sharing  of  transmission 
facilities  and  degree  of  connectivity  required  have  heavy  impact  on 
the  kind  and  architecture  of  switching  desired,  the  location  of  the 
switches,  their  capacity,  and  the  network  control  implemented.  The 
way  in  which  the  network  design  process  proceeds  is  discussed  in 
Section  V- A.  As  shown  in  Figs.  24  and  25,  the  sharing  strategy 
serves  to  define  the  major  blocks  of  ADP  users  and  ADP  centers. 

The  design  of  a common-user  (switched)  approach  will  initially 
tend  to  separate  the  network  design  from  the  more  specific  ADP-related 
factors.  In  order  to  make  the  common-user  system  as  attractive  to  as 
many  subscribers  as  possible,  only  the  general  data  flow  characteris- 
tics of  generic  users  and  their  locations  can  be  considered  initially. 
The  ADP  sites  are  differentiated  from  terminal  sites  principally  in 
their  high  volume  of  data  flow  and  geographic  location. 

In  this  approach  the  ADP  subscribers  must  make  individual  adjust- 
ments to  bring  their  sites  on-line  to  the  common-user  network.  As  ADP 
subscribers  join  the  network,  undesirable  network  features  would  be 
deleted,  new  features  added  as  needed,  and  network  refinement  made 
as  experience  and  subscriber  confidence  are  gained.  Network  architec- 
ture and  topological  guidelines  that  must  be  stipulated  for  initial 
network  layout  have  included  network  management  and  control  consider- 
ations as  well  as  expected  traffic  flow  models  derived  from  user  loca- 
tions and  flow  densities.  Factors  relating  to  ADP  subscriber  issues 
have  not  yet  been  able  to  be  included  in  initial  network  planning. 
Consequently,  there  is  the  potential  that  network  switching  and  inter- 
face decisions  can  be  made  which  are  not  fully  cognizant  of  the  poten- 
tial ADP  subscriber  problems. 

It  is  assumed  that  as  the  common-user  system  evolves,  the  many 
detailed  problems  relating  to  data  standards , interfaces , access , 
network  control,  impact  on  ADP  site  operations,  etc.,  will  be  solved 
or  satisfactorily  ameliorated.  Behind  this  assumption  is  the  belief 
that  the  attractive  features  of  a common-user  network  will  cause 
computer  technology  and  data  network  development  to  draw  together 
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sufficiently  to  justify  the  assumption.  Unfortunately,  there  does 
not  appear  at  this  time  any  concrete  technical  way  of  substantiating 
in  advance  the  viability  of  the  common-user  network.  At  this  juncture, 
only  additional  development  activity  in  common-user  network  technology 
to  specifically  define  the  major  problems  and  provide  an  environment 
to  experimentally  pursue  their  solution  could  indicate  the  future 
viability  of  a common-user  data  network. 

Several  alternate  opportunities  for  network  testbeds  avail  them- 
selves such  as; 

• Utilize  one  or  several  commercial  nets  such  as 
proposed  by  the  VANs 

• Conduct  experiments  with  one  or  more  DoD  networks 
such  as  ARPANET,  PWIN,  and  SATIN  IV 

• Initiate  a new  testbed  network. 

Another  alternative  would  be  to  delay  immediate  network  test  activity, 
while  pursuing  further  analytical  refinement  and  collection  of  DoD 
teleprocessing  requirements  on  the  one  hand  while  awaiting  new  data 
transmission  service  offerings  by  the  Common  Carriers  (see  Section 
VI -A). 

C.  NETWORK  DESIGN  PROBLEMS 


In  this  section,  a short  survey  is  provided  of  some  of  the  design 
and  analysis  efforts  that  have  been  reported  in  the  open  literature. 
These  were  taken  to  be  illustrative  of  some  of  the  types  of  problems 
addressed  and  to  provide  by  example  a feel  for  what  types  of  problems 
have  been  of  concern  and  received  some  analysis.  The  papers  selected* 
here  were  chosen  from  those  known  to  the  authors  according  to  the 
criteria  that  they  illustrate  some  problem  of  significance  and  provide 
a point  of  departure  for  those  readers  with  technical  interest  to  pur- 
sue the  subject.  They  all  address  some  feature  of  a teleprocessing 
network  design  problem.  None  addresses  the  problems  relating  to  ADP 
use  of  the  network,  data  standards,  protocols,  and  the  like.  Much  of 
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Many  of  these  enjoy  the  convenient  property  of  being  located  in  the 
same  publication. 
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the  work  reported  was  prompted  by  the  activities  of  ARPANET  and/or 
a Common  Carrier. 

1.  Overview  and  ARPANET 

An  overview  of  a selected  set  of  teleprocessing  systems  is  pro- 
vided in  Ref.  30.  A useful  and  very  extensive  bibliography  on  com- 
puter networks  is  kept  current  at  the  National  Bureau  of  Standards 
(Ref.  31).  Sampling  of  various  analytical  skills  employed  in  tele- 
processing network  design  is  provided  with  selective  problem  areas 
discussed  in  the  book  by  Abramson  and  Kuo  (Ref.  32).  Treatment  in 
greater  depth  of  dedicated  centralized  system  design  is  given  in  the 
books  (Refs.  33,  34)  by  James  Martin.  A description  of  four  large 
networks'  operations  is  given  in  Ref.  23.  A sophisticated  model  and 
analysis  of  the  communications  for  a class  of  centralized  teleprocess- 
ing systems  are  presented  in  Ref.  35.  Formulas  are  developed  to 
estimate  system  behavior  (line  and  buffer  capacity  system  throughput, 
data  delay,  buffer  overflow  probability,  etc.).  This  includes  both 
Star  and  Loop  networks. 

An  overview  of  topological  features  of  data  network  analysis  is 
given  by  Frank  and  Chou  (Ref.  25).  An  initial  investigation  of  the 
flow  properties  of  a store- and- forward  message  (e.g.  , packet)  network 
was  provided  by  Kleinrock  (Ref.  36).  The  mathematical  basis  for  tech- 
niques of  network  flow  optimization  is  presented  by  Frank  and  Frisch 
(Ref.  37).  A synopsis  of  the  design  effort  leading  to  the  ARPANET  con- 
figuration is  given  in  Ref.  37.  A current  assessment  of  remaining 
problems  and  proposed  design  refinements  for  the  communication  subnet 
of  the  ARPANET  is  contained  in  Ref.  5.  Recent  progress  in  analytical 
refinements  of  the  ARPANET  communications  subnet  is  contained  in  Ref. 
28.  Reference  28  indicates  the  initiation  of  study  toward  developing 
a hierarchy  of  regional  subnets  in  a very  large  packet  network. 

2.  Flow  Control 

A significant  problem  in  a packet  network  is  the  control  of  traf- 
fic flow,  both  overall  total  flow  and  its  user  components.  (In  a cir- 
cuit-switched network  this  type  of  problem  is  less  complex.)  In 
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Ref.  38,  the  problem  of  congestion- induced  nodal  blockage*  in  a packet 
network  was  examined.  An  investigation  is  made  as  to  the  stability  of 
node  blockage.  That  is  to  say,  will  an  overloaded,  hence  blocked,  node 
cause  its  neighbors  to  overload  and,  if  so,  will  this  in  turn  lead  to 
large  portions  of  network  blockage  (instability)?  This  is  an  interest- 
ing paper  that  shows  unstable  conditions  can  develop.  Even  in  stable 
conditions,  blocked  nodes  can  occur  in  clumps.  Unfortunately,  there 
appears  to  have  been  no  further  study  of  this  problem. 

A paper  by  Price  (Ref.  39)  utilizes  simulation  to  evaluate  the 
control  of  network  congestion  by  limiting  the  total  number  of  in- transit 
data  packets  within  the  network.  The  technique  used,  isarithmic ,** 
was  proposed  by  Davies  (Ref.  40).  Of  principal  concern  was  the  inter- 
action of  flow  control  and  adaptive  routing. 

Another  example  of  a flow  control  problem  is  the  balance  between 
user  components  of  the  total  flow.  That  is  to  say,  how  does  one  pre- 
vent a subset  of  users  with  peak  demand  from  blocking  out  other  on- 
line users  of  the  network?  Some  insight  to  this  problem  is  provided 
in  the  paper  by  Pennotti  and  Schwartz  (Ref.  41)  who  investigate  the 
delay  effects  on  other  network  users  when  one  subscriber  overloads 
the  network  with  his  traffic  over  a fixed  route.  The  increased  delay 
or  throughput  reduction  caused  to  the  other  network  subscribers  is 
examined  with  respect  to  two  representative  types  of  subscriber  flow 
control.  One  type  referred  to  as  end-to-end  control  limits  at  net- 
work access  points  the  allowed  instantaneous  in-transit  message 
(packets)  between  any  subscriber  source-destination  pair.  (This  is 
similar  to  control  used  in  ARPANET.)  The  second  type,  known  as  local 
control,  limits  the  allowed  peak  number  of  subscriber  paired  source- 
destination  packets  at  each  of  the  nodes  within  the  network  (as  opposed 
to  the  subscriber  network  access  point) . Results  of  this  investigation 

— K 

A condition  whereby  the  node  cannot  accept  more  incoming  messages, 
e.g. , buffer  overflow. 

** 

A method  for  keeping  a constant  number  of  packets  in  the  network  by 
creating  and  destroying  "empty  packets"  to  fill  in  unused  network 
capacity. 
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for  simple  networks  show  no  significant  preference  between  the  examined 
control  strategies  but  the  results  dramatically  demonstrate  the  need  for 
controlling  peak  demand  from  individual  users.  With  no  control,  peak 
demand  from  a user  can  effectively  block  out  other  users  over  major 
portions  of  the  network. 

The  paper  by  Torbett  and  Harrison  (Ref.  42)  examines  the  con- 
gestion problem  with  regard  to  establishing  user  priorities  on  net- 
work nodal  processing  of  packets.  Packet  prioritization  is  a method 
for  achieving  a form  of  user  preempts  analogous  to  those  used  in 
AUTOVON.  The  objective  of  the  study  was  to  study  nodal  scheduling 
strategies  for  handling  prioritized  packets.  This  effort  utilizes 
esoteric  mathematical  (econometric)  techniques  to  demonstrate  the 
existence  and  characteristic  of  optimal  control  (node  scheduling)  over 
the  prioritized  packets.  These  suggest  a different  approach  than  is- 
arithmetic  control. 


3.  Reliability/Survivabilit\ 


In  a paper  by  Hansler  et  al.  (Ref.  43)  the  communications  reli- 
ability design  factors  for  centralized  teleprocessing  systems  are 
investigated  and  optimization  techniques  discussed.  Wilkov  (Ref.  44  ) 
utilizes  the  theory  of  probabilistic  graphs  to  define  and  charac- 
terize various  reliability  measures  for  data  networks.  The  author 
points  out  the  serious  lack  of  theory  to  account  for  network  degra- 
dation resulting  from  failure  in  network  elements  due  to  traffic 
overload  and  encourages  further  effort  in  that  direction. 


A report  to  the  Board  of  Governors  of  the  Federal  Reserve  System 
(Ref.  45)  examines  the  conceptual  design  and  cost  of  an  ARPANET  type 
of  network  for  the  Electronic  Funds  Transfer  System.  By  optimal  ad- 
dition of  redundant  communication  links  at  given  levels  of  increased 
system  cost,  the  expected  loss  of  service  is  obtained  as  a function 
of  the  probability  of  any  one  link  failure.  For  very  marginal  in- 
crease in  transmission  costs,  very  dramatic  (exponential)  improvement 
is  predicted.  For  a 2 percent  increase  in  transmission  costs,  the 
same  level  of  system  outage  could  be  obtained  at  a doubling  of  link 
failure.  A summary  of  these  results  is  presented  in  Ref.  21. 
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Study  of  network  survivability,  which  is  of  especial  importance 
to  Type  la  teleprocessing  systems  (Section  III),  utilizes  many  of  the 
analytic  tools  used  in  studies  of  network  reliability  but  with  dif- 
ferent objective  functions.  A paper  by  Frank  (Ref.  46)  provides  an 
overview  of  this  problem  and  discusses  various  measures  of  network 
survivability.  Several  examples  of  network  survivability  issues  and 
their  analysis  are  discussed.  Suggested  areas  for  further  theoretical 
development  include  incorporation  of  time  dependence  (time  sequence 
attack,  survivability  through  time),  correlated  network  effects, 
multi- commodity  analysis  for  multiple  command  centers  and  the  inter- 
action of  network  survivability  and  operational  procedures. 

4.  Packet /Circuit  Switching  Comparisons 

The  comparative  analysis  of  circuit  versus  packet  switching  is 
quite  complex.  A very  illustrative  example  of  the  factors  involved 
is  provided  by  Clowes  and  Jayasuriya  (Ref.  47).  User  population  and 
type  of  service  are  postulated  in  order  to  generate  a traffic  flow 
model.  Then  four  different  network  topologies  utilizing  packet  and 
circuit  switching  are  configured  to  minimize  the  number  of  (4  kbps) 
channel  miles  in  the  network.  Variations  in  topology  and  packet 
length  were  included.  For  the  traffic  model  used  and  the  performance 
measure*  "channel  miles,"  the  results  showed  considerable  reduction 
in  required  channel  miles  by  using  packet  switching  rather  than  cir- 
cuit switching.  However,  the  packet -switch  nodal  throughput  require- 
ment becomes  very  large.  A hybrid  switching  network  was  also  con- 
sidered wherein  interactive  traffic  was  packet- switched  and  bulk 
traffic  circuit- switched.  This  configuration  reduced  the  channel 
miles  used  from  that  of  the  all-circuit  switched  network  but  still 
significantly  exceeded  those  of  the  packet  system.  However,  the 
switch  nodal  throughput  requirements  (and  hence  cost)  were  consider- 
ably reduced  over  the  all- packet  system.  The  authors  conclude  that 
the  hybrid  approach  appears  promising  in  that  it  provides  greater 


This  measure  directly  relates  to  transmission  charges  for  long-haul 
dedicated  trunks.  It  does  not,  however,  include  the  costs  of  the 
switches. 
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flexibility  to  accommodate  wider  variation  in  user  data  characteris- 
tics and  traffic  parameters. 


The  paper  by  Itoh  and  Kato  (Ref.  48)  also  compares  packet-  and 
circuit- switched  networks.  Utilizing  a set  of  interlocking  models  of 
traffic  flow  and  network  operation,  together  with  hardware  component 
costs,  the  authors  estimate  the  overall  data  network  costs  (including 
switching  costs)  for  packet-  and  circuit- switching  network  realizations. 
An  important  assumption  is  the  use  of  an  all-digital  transmission  sys- 
tem and  time-division  all-digital  circuit  switching.  The  paper  de- 
velops sets  of  tradeoff  curves  between  access  line  speed  and  user  cir- 
cuit holding  time.*  On  one  side  of  the  curve,  circuit  switching  is 
preferred  (faster  line  speed,  longer  holding  time)  while  on  the  other 
packet  switching  is  indicated  (slower  line  speed,  shorter  holding  time). 
As  an  example  under  the  model  and  assumptions  used,  it  is  concluded 
that  packet  switching  is  preferable  for  an  access  line  speed  of  2.4 
kbps,  and  any  holding  time  less  than  10  sec  (i.e.,  data  blocks  shorter 
than  24  Kbytes  or  3000  characters). 

Although  not  a comparison  of  packet  versus  circuit  switching, 
the  paper  by  Verma  and  Rybcznski  (Ref.  49)  is  of  interest  in  that  it 
addresses  whether  data  users  with  different  message  lengths  should  be 
segregated  or  integrated  on  the  same  transmission  line.  The  problem 
considered  is  whether  to  share  or  to  separate  service  to  two  data 
sources  having  different  average  message  lengths.  The  average  trans- 
mission delay  to  each  user  is  compared  between  using  separate  channels 
or  sharing  a common  channel.  The  two  users  are  assumed  to  both  have 
geometrically  distributed  message  lengths  but  to  have  different  aver- 
age length.  The  paper  shows  significant  improvement  in  average  delay 
by  assigning  separate  channels  to  the  two  users  provided  the  average 
length  of  the  longer  message  is  greater  than  ten  times  that  of  the 
shorter.  When  the  ratio  of  average  message  lengths  between  the  two 
users  exceeds  ten,  the  average  delay  in  message  delivery  on  the  shared 
channel  increases  exponentially. 


i 


5.  Access  Performance 

Several  interesting  papers  address  the  problem  of  an  ADP  or  termi- 
nal site  interacting  with  a communications  line.  These  papers  are  all 


characterized  by  their  examining  the  data  transfer  performance  between 
ADP  users.  They  can  be  of  use  in  analyzing  the  network  access  problem. 
The  Star  or  Tree  centralized  configuration  can  be  useful  in  structuring 
the  local  transmission  of  terminals  to  an  access  point  of  the  backbone 
network. 

In  the  paper  by  Spragins  (Ref.  50),  results  are  presented  of  a 
simulation  of  the  overload  characteristics  of  a com  front  end  at  the 
central  computer  site  of  a Star  network.  The  author  concludes  that 
system  load  saturation  of  the  com  front  end  is  extremely  sharp.  In 
a separate  paper  (Ref.  51),  Spragins  uses  a simplified  queueing  model 
to  analyze  a computer  I/O  port  connected  to  terminals  on  a loop  or  ring 
access  line.  Of  principal  interest  here  is  the  expected  waiting  time 
to  deliver  a message  which  then  determines  the  terminal  buffering 
requirements.  In  the  paper  by  Hayes  (Ref.  27),  a combined  approach 
of  analytical  and  computer  simulation  is  used  to  investigate  the  per- 
formance of  a looped  Star  system  using  time-division  demand  access  by 
terminals  located  on  the  loops  which  are  all  digital  high-speed  line 
(T-l,  1.5  Mbps).  At  the  center  of  the  loops  is  a control  and  switch- 
ing computer  which  routes  traffic  between  loops.  Throughput,  delay, 
and  buffer  overflow  are  studied  as  a function  of  number  of  terminals 
for  several  switching/control  strategies. 

6.  Buffer  Analysis 

Techniques  useful  for  analyzing  buffer  requirements  for  communi- 
cations devices  (terminals,  front  ends,  contrators , packet  switches, 
etc.)  are  illustrated  in  papers  by  Chang  (Ref.  52)  and  Chu  (Ref.  53). 
Several  buffer  management  strategies  are  examined.  Results  of  this 
type  are  of  considerable  utility  considering  the  large  distributed 
use  of  buffers  in  teleprocessing  systems.  In  a paper  by  Closs  (Ref. 
54),  a model  is  presented  for  sizing  the  buffer  requirements  of  a 
packet  switch  as  a function  of  access  lines  and  trunk  line  speed. 


7 . Architecture  and  Performance  Modeling 


Of  central  interest  to  teleprocessing  decision  making  is  the 
development  of  methods  for  studying  and  evaluating  system  organization 
and  architecture.  It  is  the  lack  of  such  a capability  that  represents 
one  of  the  greatest  difficulties.  The  six  previous  subsections  out- 
line pieces  of  the  overall  problem.  In  a sense,  the  question  arises 
that  given  adequate  subarea  methodologies , how  does  one  put  them  to- 
gether? 

A key  manifestation  of  this  issue  is  the  current  interest  in  pro- 
jecting where  the  future  trend  will  develop  between  the  two  different 
extremes:  centralized  superprocessing  centers  with  smart  terminals, 
i or  decentralized  processing.  The  answer  will  clearly  lie  between  the 

two;  in  fact,  there  may  be  several  answers  (i.e.  , operational  teleproc- 
essing systems)  depending  on  the  specialized  needs  of  user  communities 
and  market  conditions  (i.e.,  technology  and  cost).  A preliminary  and 
simplified  mathematical  model  is  advanced  in  the  paper  by  Streeter 

, . (Ref.  55).  Principal  aggregate  parameters  are  identified  (nodal  proc- 

L 

essing  power,  network  capacities,  task  delay,  etc.)  and  cost  performance/ 
functionals  are  postulated  for  these  parameters.  The  model  assumes  large 
regional  ADP  service  centers  that  are  interconnected  to  satellite  sub- 
centers. This  concept  of  operation  is  similar  to  that  of  Ref.  2.  The 
analysis  proceeds  with  configuring  the  distribution  of  nodal  capacity 
with  regard  to  the  postulated  functionals  for  a given  level  of  perform- 
ance. The  results  of  Ref.  55  show  a definite  trend  to  centralization. 

A conceptually  similar  approach  was  taken  in  Ref.  3 where  one 

or  only  a very  few  central  systems  were  studied.  Here,  however, 

instead  of  postulating  generalized  cost  functions  for  communications 

and  system  loading  demand  actual  tariff  schedules  were  used  with  more 
* I 

detailed  terminal  statistics.  Consequently,  '’optimum"  network  topol- 
ogies were  obtained  as  part  of  the  overall  cost  comparison.  Littrell 
r in  Ref.  56,  using  test  run  simulation  techniques,  studies  and  compares 

the  task  throughput  performance  of  the  IBM  360/370  series  computers.* 

The  studied  machine  tasks  have  the  machines  operating  in  a multiprogram 


* 


batch  mode.  In  contrast  to  the  results  of  Refs.  3 and  55,  Ref.  56  shows 
no  advantages  in  centralizing  ADP  for  business-oriented  (as  opposed  to 
scientific)  data  processing  tasks.  The  different  results  follow  from 
different  assumptions,  objectives,  and  projected  (or  capability-specific) 
processor  capability. 

For  the  interested  reader,  Ref.  57  discusses  a study  of  upgrading 
an  IBM  360/50  installation  to  a 360/65  or  adding  a communications  front 
end  to  the  existing  360/50.  The  principal  utility  of  the  paper  is  in 
exhibiting  the  detail  of  economic  factors  to  be  addressed,  the  heavy 
dependence  on  system  simulation,  and  hence  the  dependence  on  the  spe- 
cifics of  particular  equipment.  It  is  worth  observing  with  regard  to 
Ref.  57  that  the  simulation  and  evaluation  programs  used  are  proprietary 
to  the  authorrs  parent  company.  One  of  their  sources  of  business  is 
supplying  teleprocessing  guidance  to  customer  specific  system  con- 
figuration. 

D.  SUMMARY 

Teleprocessing  system  design  and  analysis  are  very  complex  sub- 
jects with  a very  large  number  of  variables  and  design  options  all 
impacting  performance  and  cost.  A good  general  understanding  of  the 
relationships  between  these  variables  is  not  available.  Techniques 
and  predictions  of  expected  performance  have  developed  within  the 
context  of  current  use  of  the  telephony  plant  as  a support  element  to 
a (set  of)  computer  center(s).  As  such,  the  analysis  is  specialized 
by,  and  the  results  limited  to,  the  particular  configuration  and  oper- 
ational constraints  of  specific  vertically  integrated  systems.  Only 
recently,  as  an  outgrowth  of  ARPANET,  are  analytical  design  tools 
being  evolved  that  are  applicable  to  the  study  of  subscriber-oriented 
data  networks. 

The  design  problem  can  be  broken  into  three  subareas:  (1)  user 
characteristics  and  demand,  (2)  ADP  processing,  and  (3)  communication 
network.  All  three  areas,  unfortunately,  are  highly  interdependent. 
Conventional  design  of  dedicated  systems  emphasizes  areas  (1)  and  (2) 
which  generate  data  flow  models.  The  communication  network  (3)  is 
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then  chosen  to  support  data  flow  generated  by  (1)  and  (2)  at  least 
annual  cost.  These  user  and  ADP  areas  specify  network  topological 
guidelines,  operational  constraints,  and  other  system  specific  fac- 
tors. The  network  objectives  chosen  and  the  resulting  design  then 
reflect  these  constraints.  Whether  designing  dedicated  vertically 
integrated  systems  or  distributed  common-user  systems,  the  network 
configurations  chosen,  as  to  communication  routes  and  bandwidth  selec- 
tion, are  all  dependent  on  transmission  tariff  schedules.  (Changes 
in  the  tariff  schedules  will  motivate  network  reconfiguration.) 

On  the  other  hand,  design  of  common-user  networks  emphasizes 
separation  between  area  (3)  and  areas  (1)  and  (2).  Moreover,  in  con- 
trast to  a dedicated  design,  generalized  network  objectives  are  re- 
quired that  are  not  as  sensitive  to  specific  subscribers  (terminals, 
computers).  This  design  process  involves  risks  which  as  yet  are  not 
fully  understood,  especially  in  network  access  and  flow  control.  In- 
adequate solutions  to  these  problems  can  impede  providing  technically 
adequate  and/or  economically  attractive  data  communication  service 
to  a sufficiently  large  community  of  subscribers  to  make  the  common- 
user  network  viable. 

There  are  many  possible  modes  for  sharing  communication  facili- 
ties (e.g.,  access  lines,  concentrators , long-haul  transmission)  in- 
termediate between  dedicated  and  common-user  networks.  The  user  ob- 
jectives and  sharing  arrangement  will  influence  switching  require- 
ments. One  of  the  more  interesting  sharing  modes  is  a piggyback 
communications  service  provided  by  a large  geographically  distrinuted 
teleprocessing  system  to  smaller  systems. 

A review  of  the  technical  literature  with  regard  to  network 
analysis  shows  considerable  diversity  of  approach  and  interest  with 
little  coordination  between  research  problems.  Theoretical  techniques 
are  only  in  their  infancy.  There  is  a heavy  reliance  on  computer 
analysis  either  for  simulation  of  specific  system  configuration  solu- 
tion network  using  or  intelligent  exhaustive  search  (heuristic  pro- 
gramming) . 
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Initial  comparisons  between  packet-  and  circuit- switching  networks 
show  dependence  on  user  characteristics,  types  of  data  (transmission, 
bulk),  load  level,  and  geographic  distribution,  as  well  as  sensitivity 
to  technology,  cost  and  comparison  measure  chosen.  Packet  technology 
does  appear  attractive.  However,  a hybrid  packet-  and  circuit- switch 
design  may  be  the  most  desirable  approach  for  segregating  bulk  from 
transactional  data,  mitigating  the  access  and  flow  control  problem, 
and  achieving  flexible  reconfiguration  of  the  network  to  changes  in 
user  characteristics.  Areas  are  identified  in  Section  VII  requiring 
future  R&D  effort. 
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VI.  COMPUTER  AND  DATA  COMMUNICATION  FUTURE  ENVIRONMENT 

This  section  and  Appendix  B present  a summary  of  projected  de- 
velopments by  the  1980s  in  communications  facilities  and  computer 
equipment.  It  is  important  to  have  some  estimate  of  the  possible 
technical  context  from  which  teleprocessing  components,  systems,  and 
applications  will  evolve  and  thus  set  the  technical  possibilities  for 
data  networks.  Development  of  policies  and  alternatives  for  guiding 
the  acquisition  of  teleprocessing  systems  in  general,  and  in  DoD  in 
particular,  cannot  btj  insensitive  to  the  direction  in  which  communi- 
cations and  ADP  activities  are  progressing. 

il. 

\ 

This  section  reports  on  the  Efforts  devoted  to  examining  communi- 
cation developments  related  to  teleprocessing.  However,  because  of 
the  limited  resources  available  to  this  study  and  the  relevance  and 
recent  availability  of  the  SADPR-85  (Ref.  2)  study  containing  compa- 
rable projected  developments  in  computers , it  was  decided  not  to  ex- 
pend further  study  effort  on  a computer  technology  forecast.  This 
computer  technology  forecast  and  assessment  were  prepared  by  Arthur  D. 
Little  Co.  , under  contract*  to  AFESD  (Air  Force  Electronic  Systems 
Division)  as  part  of  the  SADPR-85  effort.  Their  report  is  included 
as  Volume  3,  Appendix  VI  of  Ref.  2.  To  make  the  present  report  self- 
contained,  the  summary  of  the  ADL  report  as  contained  in  Volume  1 of 
the  SADPR-85  report  is  reproduced  here  as  Appendix  B. 


Air  Force  Contract  F19628-74-C-0093. 
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COMMUNICATIONS 


A. 

1.  Introduction 

The  currently  available  communication  transmission  facilities 
and  services  are  in  a rapid  state  of  transition.  This  section  at- 
tempts to  provide  only  a synopsis  of  the  current  situation  and  pro- 
ject developments  of  data  communications.  The  principal  emphasis, 
besides  providing  a communication  context,  will  be  to  examine  some 
of  the  potential  impacts  on  teleprocessing  network  development  that 
derive  from  expected  changes  in  communications. 

Present  network  design  and  planning  are  predicated  on  currently 
available  communication  facilities  and  existing  tariff  structure. 

New  service  offerings  and  tariffs  are  on  file  with  the  FCC  from  Com- 
mon Carriers,  and  Specialized  Carriers  (including  the  VANs).  Con- 
sequently, it  seems  appropriate  first  to  review  the  present  data 
communication  environment  and  then  project  the  expected  future  de- 
velopments for  impact  on  teleprocessing  systems. 

2.  Current  Environment 

a.  Current  Telephone  Plant.  The  current  data  communication 
environment  is  predicated  on  utilizing  the  transmission  facilities 
of  the  existing  analog  telephone  and  data  plant  provided  by  the 
Common  Carriers,  principally  the  Bell  System,  GTE,  and  Western  Union. 
For  long-haul  transmission  circuits,  this  plant  consists  of  a large 
mix  of  wideband  cable  and  microwave  radio  transmission  and  tandem 
circuit  switches.  For  local  service  and  access  to  the  long-haul  cir- 
cuit, the  "twisted  pair"  telephone  local  loops  connect  the  subscribers 
to  a central  telephone  office  of  a local  telephone  company  where  calls 
are  initially  switched  and  individual  local  circuits  are  aggregated 
(multiplexed)  into  larger  bandwidth  channel  groups  for  sharing  the 
wideband  long  distance  circuits.  An  example  of  the  channel  bandwidth 
multiplex  hierarchy  is  shown  in  Fig.  27  taken  from  Ref.  58  which 
summarizes  the  AT&T  facilities. 


138 


17  548  MH/ 


60  556  MH; 


12  vf 
Channels 


9 Other 
Basic 

Supergroups 


8884  o 
8 524  6 


rC 


5 Other 
Basic 

Mastergroups 


3 Other 
Basic 

Jumbo  Groups 


FIGURE  27.  Analog  Hierarchy  (Ref.  58) 

Current  data  communications  utilize  this  plant  through  a basic 
4-kHz  wide-voice  channel  on  a dial-up  basis  or  on  a dedicated  lease 
basis  (which  allows  obtaining  wider  bandwidth  channels).  Utilizing 
the  basic  voice  channel  usually  permits  using  an  existing  local  loop. 
Wider  band  dedicated  service  can  require  new  local  transmission  lines 


A new  technique,  synchronous  line  multiplex,  uses  a high-speed  local 
loop  with  multiplexed  terminals  to  reduce  the  local  connection  charges. 
The  on-base  communications  (AFBITS)  of  the  SADPR-B5  (Ref.  2)  concept 
employs  this  technology. 

In  addition  to  various  channel  bandwidth  offerings , dedicated 
lines  can  also  be  ordered  (at  higher  cost)  with  conditioning  to  up- 
grade the  quality  of  service  principally  to  improve  the  electrical 
transmission  parameters  and  lower  the  noise  level.  This  conditioning 
permits  higher  data  transmission  speed  for  a given  bandwidth  and  re- 
duces error  rate.  Table  12*  compiled  by  ADL  in  Ref.  2,  Volume  3, 
summarizes  some  of  the  currently  available  services. 


TABLE  12.  DATA  TRANSMISSION  SERVICES  AVAILABLE 


FROM  AT&T 

(Early  1970s) 

(Ref.  2) 

Half-Duplex  or 

Leased  or 

Speed  (bps) 

Service  (Series) 

Full  Duplex 

Switched 

Subvoice 

45 

1002 

FDX/HDX 

L 

55 

1002 

FDX/HDX 

L 

75 

1005 

FDX/HDX 

L 

150 

1006 

FDX 

L 

Voice  Grade 

0-300 

Data-Phone 

FDX 

S 

0-1200 

Data-Phone 

HDX 

S 

1200 

3002 

FDX/HDX 

L 

1400 

3002,  Plus  Cl 

FDX/HDX 

L 

2000 

Data-Phone 

HDX 

S 

2400 

3002,  Plus  C2 

FDX/HDX 

L 

3600 

Data-Phone 

HDX 

S 

4800 

3002,  Plus  C4 

FDX/HDX 

L 

7200 

3002,  Plus  C4 

FDX/HDX 

L 

9600 

3002,  Plus  C4 

FDX/HDX 

L 

Wideband 

19,200 

8803 

FDX 

L 

40,800 

8801 

FDX 

L 

105,000 

5700 

FDX 

L 

230,400 

5700  or  5800 

FDX 

L 

500,000 

5800 

FDX 

L 

This  table  includes  modem  offerings  which  are  subsequently  discussed 
in  this  section.  The  Cl,  C2,  and  C4  indicate  type  of  line  conditioning. 
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b.  Tariff  Structure.  The  variety  of  the  current  Common  Carrier 
transmission  offerings  have  been  standardized  as  to  offered  bandwidths , 
levels  of  conditioning,  and  full-  or  half-duplex  circuits.  To  this 
is  added  a rather  complex  cost  structure*  for  the  various  available 
services.  The  structure  revolves  around  fixed  monthly  connection 
charges  plus  time  and  distance  charge  for  long-distance  dial-up  calls. 
For  large  volume  use,  the  larger  users  can  buy  service  in  bulk 'with  the 
wide-area  telecommunication  service  (WATS)  that  provides  dial-up  service 
with  its  own  (complex)  tariff  structure  depending  on  volume  level, 
distance,  and  time  of  day  usage.  For  leased  nonswitched  dedicated 
channels,  a structure  of  monthly  tariffs  per  unit  channel  bandwidth 
per  airline  mile  is  imposed.  This  latter  service  when  purchased  in 
bulk  quantities  is  typified  by  Telpak  charges.  [Note  that  dedicated 
service  (e.g. , Telpak)  need  not  be  limited  to  data.  It  is,  in  fact, 
used  principally  for  private  intracorporate  telephony  communications 
between  geographically  dispersed  facilities  of  the  corporation  leasing 
the  service.]  A further  complication  in  tariff  structure  is  the  dif- 
ferentiation between  intrastate  and  interstate  circuits. 

A very  significant  cost-savings  opportunity  for  subscribers  with 
large  bulk  purchase  of  transmission  capacity  is  the  optimization  of 
leased  network  topology  to  yield  minimum  cost  for  specific  traffic- 
flow  requirements.  Considerable  savings  can  be  achieved  (Refs.  59, 

60)  just  through  optimized  aggregate  bulk  purchase  of  trunk  capacity 
with  optimization  of  the  network  topology.  The  optimum  network 
topology  chosen  (node  location  and  trunk  linkages  with  associated 
bandwidth)  is  sensitive  to  the  tariff  structure  and  particular  going 
rates  within  the  structure.  The  optimization  procedure  is  far  from 
simple  and  is  capable  of  exploiting  the  vagaries  of  the  tariff 
schedule.  Thus,  significant  changes  in  the  tariff  rates  or  struc- 
ture are  by  themselves  strong  motivation  to  reconfigure  a data  net- 
work and  system  operation. 

A simplified  example  of  this  tariff  structure  is  displayed  in 

Table  13  in  the  next  section  for  the  Bell  System  Digital  Data 

Service  (DDS). 


As  an  example  of  some  of  the  inconsistencies  that  have  evolved 
within  the  tariff  schedule,  Fig.  28  (Ref.  61)  shows  averaged  monthly 
unit- bit-rate  cost  with  distance  of  various  speed  lines.  In  con- 
travention to  usual  expectation,  at  a distance  in  excess  of  350  miles, 
the  per-unit-bit-rate  monthly  cost  of  the  lower  speed,  9.6-kbps  line, 
is  less  than  the  50-kbps  line  and  at  2000  miles  equals  the  230-kbps 
line.  Thus,  excluding  modem,  terminal  costs,  etc.,  a customer  who 
can  subdivide  his  bulk  purchase  into  units  of  9.6  kbps  is  better  off 
ordering  such  submultiples  at  distances  greater  than  350  miles  than 
he  would  if  he  aggregated  his  buy  into  a 50-kbps  line. 


11-19-74-1 


FIGURE  28.  Average  Unit  Digital  Transmission  Cost  Versus  Distance 
for  Three  Bit  Rates  (Ref.  61) 


c.  Modems,  Concentrators,  Com  Front  Ends.  Data  transmission 
within  the  existing  telephony  plant  must  utilize  modems  to  electri- 
cally convert  digital  signals  utilized  by  ADP  devices  into  signal 
waveforms  suitable  for  transmission  on  the  analog  plant.  There  are 
numerous  types  of  modems  from  well  over  40  independent  suppliers 
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(not  including  products  available  from  the  computer  manufacturer,  e.g., 
IEM,  Honeywell,  Burroughs,  Singer,  etc.,  and  the  Common  Carrier,  e.g., 
Bell  System  data  phone).  Communications  equipment  such  as  concentrators, 
multiplexers,  and  com  processors  (computer  communication  front  ends) 
must  be  utilized  in  addition  to  modems  and  transmission  lines  to  es- 
tablish the  desired  network  between  host  computers  and  their  terminals. 
The  principal  objectives  are  to  provide  sharing  of  the  transmission 
facilities  with  multiplexers  and  concentrators  and  off-load  the  burden 
of  handling  specialized  communications  functions  and  control  from  a 
CPU  site  with  com  front  ends.  The  communication  functions  can  be  very 
costly  in  taking  up  considerable  space  of  the  CPU  core  memory  as  well 
as  excessively  burdening  the  operating  system  software.  Communication 
functions  are  better  performed  by  specially  configured  and  programmed 
small  computers  which  "front  end"  the  host  computer. 

Enriching  the  available  options  and  making  complex  the  design 
choices  for  data  transmission  systems  are  considerable  overlaps  in 
network  functions  and  available  equipment.  Terminals  can  have  modems 
built  in.  Com  processors  can  and  usually  do  act  as  concentrators. 

One  can  multiplex  before  and/or  after  modems  (i.e.,  on  digital  side 
or  analog  side).  Industry  surveys  of  existing  data  communications 
equipment  and  characteristics  are  given  in  Refs.  62,  63,  and  64.  In 
Ref.  65  a recent  survey  of  minicomputers  is  presented. 

d.  Narrative  Data  (Telegraphy).  The  discussion  above  relates 
primarily  to  the  use  of  the  existing  telephone  plant.  Also  available 
for  data  transmission  is  the  telegraphy  plant*  of  Western  Union. 
Telegraphy  transmits  fundamentally  digital  data**  but  is  evolving 

Historically,  telegraphy  and  Western  Union  Telegraph  Company  con- 
siderably predate  the  telephony  industry.  Although  Western  Union 
is  one  of  the  larger  U.S.  corporations , the  telephony  industry  and 
AT&T  in  particular  have  been  growing  for  several  decades  at  twice 
the  rate  of  Western  Union  with  the  end  result  that  the  telegraphy 
plant  is  considerably  dwarfed  by  the  telephone  plant. 

rtcfc 

Morse  code  can  be  theoretically  considered  to  be  built  on  a ternary 
base  of  no  signal,  short  signal,  or  long  signal.  Modern  digital 
codes  are  built  on  a binary  base. 


from  the  use  of  primarily  an  all-analog  transmission  plant  to  a 
hybrid  analog/digital  service.  (The  features  of  digital  service  are 
discussed  in  the  ensuing  text.)  A comprehensive  review  of  Western 
Union  plant  and  offerings  including  long-haul  transmission  as  well 
as  store- and- forward  (Telex,  TWX,  Infocom)  service  is  provided  in 
Ref.  66.  Figure  29  depicts  the  geographical  coverage  of  Western 
Union’s  wideband  transmission  system.  The  previous  discussion  as 
to  the  use  of  the  telephony  plant  for  data  transmission  also  applies 
to  the  telegraphy  plant.  It  is  important  to  note,  however,  that 
Western  Union  is  providing  a switched,  store- and-forward.,  common-user, 
subscriber- oriented  narrative- data  network  service  through  TWX  and 
Telex.  For  Federal  Government  use  the  ARS  and  AUTODIN  I systems 
leased  from  Western  Union  provide  this  narrative  data  service.  These 
systems  are  currently  also  being  used  for  the  transmission  of  pri- 
marily bulk-type  ADP  data.  However,  due  to  their  long  response  time, 
these  networks  are  not  suitable  for  transactional  or  inquiry /response 
ADP  traffic. 

e.  Local  Connection.  It  is  important  to  note  here  that  although 
Western  Union  and  the  newly  emerging  specialty  carriers  provide  a 
backbone  long-haul  facility,  a subscriber  still  must  connect  from 
equipment  on  his  premises  to  the  nearest  access  point  of  the  network 
he  is  going  to  utilize.  Unless  the  particular  facility  requires  a 
very  high  access  speed  or  is  collocated  with  the  network,  the  sub- 
scriber will  have  to  traverse  the  Common  Carrier  local  telephone 
plant  to  make  the  connection  or  provide  his  own  connection.  Thus, 
without  obtaining  independent  means  of  network  access,  the  user’s 
communications  are  ultimately  limited  by  the  capabilities  and  avail- 
ability of  the  local  telephony  plant. 

There  are  two  major  implications:  one  is  cost,  the  other  regu- 
latory. The  cost  issue  is  that  conventional  modems  may  still  be  re- 
quired* to  traverse  the  telephony  local  loop  even  if  the  data  network 

Modems  can  be  eliminated  when  direct  physical  connection  is  permitted 
to  the  Bell  System’s  all-digital  local  carrier  facilities  (e.g.,  T-l) 
as  discussed  in  the  subsequent  subsection. 
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FIGURE  29.  Western  Union  Telegraph  Co.  Wideband  Systems  (Ref.  66) 


is  all  digital.  The  regulatory  or  institutional  issue  is  the  avail- 
ability of  the  local  loop  service.  Local  telephone  companies  of  the 
AT&T  Corporation  have  been  challenging  in  Federal  and  state  courts 
the  FCC  ruling  requiring  the  telephone  companies  to  provide  local 
loops  and  short-haul  circuits  between  specialty  carriers  (which  are 
competing  with  AT&T  Long  Lines)  and  their  subscribers.  Although 
AT&T  as  yet  has  not  been  successful  in  having  the  FCC  ruling  changed, 
the  final  outcome  is  still  in  some  doubt. 

3.  Future  Environment 

a.  New  Transmission  Suppliers.  With  the  encouragement  of  recent 
favorable  FCC  rulings  and  a perceived  large  potential  specialized  com- 
munications market  demand  (including  private  telephony  as  well  as 
data),  Specialized  Carriers  (as  opposed  to  Common  Carriers)  have  con- 
cluded that  they  can  implement  and  maintain  long-haul  transmission 
facilities  specially  configured  for  high-volume  customers  with  leased 
transmission  services  offered  at  rates  more  attractive  than  presently 
exist  under  the  tariff  structure  of  the  Common  Carriers.  There  are 
quite  a few  entrants  to  this  market  (two  of  the  more  publicized  being 
DATRAN  and  MCI)  including  several  newly  formed  domestic  satellite 
companies  and  the  Value  Added  Networks  (VANs).  A more  comprehensive 
review  of  these  facilities  is  provided  in  Ref.  2,  Volume  3. 

The  communications  environment  that  will  evolve  from  the  entry 
of  new  suppliers  is  uncertain.  Principal  concern  is  which  of  the 
many  newly  emerging  and  competitive  suppliers  of  long-haul  communica- 
tion services  and  which  of  their  new  services  will  survive  the  test 
of  the  competitive  marketplace.  Major  changes  in  available  communi- 
cation services  that  will  be  provided  within  the  next  few  years  are 
guaranteed  by  the  on-going  implementation  of  the  Bell  System’s  ’’all- 
digital”  DDS  facility  which  is  derived  from  the  digital  (PCM)  voice 
telephony  being  progressively  installed  locally  and  the  data  under 
voice  (DUV)  technique  used  on  the  microwave  relay  systems. 

b.  Value  Added  Networks.  Inasmuch  as  cost  savings  are  possible 
through  bulk  purchase  of  long-haul  transmission  facilities  from  the 


carriers  but  only  with  point-to-point  service,  a group  of  Specialized 
Carriers  is  forming  to  provide  switching,  concentrating,  and  other 
(e.g.,  error  control)  data  transmission  services  as  a value-added  serv- 
ice to  the  basic  long-haul  transmission.  These  Value  Added  Networks 
(VANs)  purchase  from  the  carriers  point-to-point  bulk  transmission 
and  add  the  switching  and  other  services  at  nodal  points.  There  are 
several  corporations  planning  to  offer  such  service  including  GRAPHNET, 
TELENET,  and  PCI  among  the  more  publicized.  The  newly  forming*  VANs, 
to  varying  degrees,  utilize  packet- switching  concepts  and  technology 
developed  for  the  ARPANET.  Inasmuch  as  these  VAN  networks,  although 
licensed  for  operation  by  FCC,  are  still  in  a development  stage,  sub- 
scriber data  interface  standards,  types  of  service,  geographic  cover- 
age, and  tariff  schedules  are  not  yet  finalized. 

One  VAN,  TYMNET,  is  currently  providing  operational  service  to 
ADP  subscribers.  TYMNET  (Ref.  11)  is  an  outgrowth  of  TYMSHARE,  Inc. , 
a commercial  ADP  time-sharing  service  which  made  available,  in  a piggy- 
back model,  portions  of  its  intrinsic  data  communications  support  net- 
work for  interconnexion  between  subscribers  possessing  their  own 
(rather  than  TYMSHARE)  ADP  assets  (computers  as  well  as  terminals). 

The  TYMNET  network  was  developed  independently  by  TYMSHARE  and  was 
not  derived  from  ARPANET.  The  network  objectives  in  seeking  to  mini- 
mize subscriber  interface  problems  led  to  a design  concept  of  emulat- 
ing circuit- switched  characteristics  with  a packet-type  transmission 
that  permits  statistical  multiplexing  of  transmission  circuits.  Rather 
than  use  adaptive  routing,  paired  subscriber  call  requests  are  assigned 
a route  which  is  stored  in  tables  at  the  switching  computer  nodes. 

The  route  is  retained  in  memory  until  the  call  is  taken  down.  How- 
ever, trunk  transmission  capacity  is  only  used  "by  the  packet." 


It  is  important  to  note  that  predating  ARPANET,  a privately  operated 
value-added  packet-type  network,  SITA,  has  been  successfully  in  use. 
A description  of  SITA  and  contrast  with  ARPANET  is  given  in  Ref.  20. 


The  VAN  concept  closely  resembles  a common-user  data  network 
such  as  DoD  might  employ.  The  development,  evolution,  and  opera- 
tional experience  of  the  VAN  concept  should  be  of  considerable  in- 
terest to  DoD  for  potential  use  and/or  technology  transfer. 

c.  New  AT&T  Transmission  Offerings.  In  partial  response  to  the 
emerging  competition  in  supply  of  communication  services,  AT&T  has 
filed  with  the  FCC  a new  tariff  structure  known  as  the  Hi/Lo  Density 
Rate.  With  FCC  approval,  the  AT&T  rates  would  be  reduced  on  those 
routes  with  high-traffic  density  and  increased  on  those  routes  with 
low-traffic  density.  Data  subscribers  would  still  utilize  the  present 
analog  telephony  plant  but  with  drastically  altered  tariff  structure. 

If  accepted,  and  with  no  change  in  transmission  facilities  or  service, 
this  proposed  tariff  change  in  its  own  right  will  produce  a strong 
motivation  for  subscribers  with  significant  data  transmission  needs 
at  the  very  least  to  reoptimize  their  current  network  configurations 
and  alter  their  mode  of  operation  to  include  reconfiguring  computer 
facilities  and  terminals. 

AT&T  is  in  the  process  of  implementing  their  Digital  Data  System 
(DDS)  network.  This  data  network  is  already  offered  locally  in  ten 
cities  and  will  expand  to  cover  approximately  99  major  U.S.  cities  by 
the  end  of  1976.  A tentative  plan  for  geographical  coverage  by  the 
DDS  network  for  1975  is  shown  in  Fig.  30  . At  present  the  only  an- 
nounced service  offered  is  leased  point-to-point  data  transmission 
in  multiples  of  2.4-kbps  data  speeds.  An  illustrative  example  of  the 
proposed  point-to-point  tariff  structure  for  this  (Ref.  2 ) is  shown 
in  Table  13. 

AT&T  has  not  publicly  announced  any  plans  for  providing  data 
switching  service  in  the  DDS.  It  is  possible*  that  at  some  future 

The  Bell  Labs  have  disclosed  (Ref.  67)  development  work  on  the  ESS  #4 
switch  which  will  be  an  all-digital  time-division  trunk  circuit  switch 
which  will  support  conventional  trunks  as  well  as  PCM  carriers  (T-l). 
The  switch  controller  (which  it  is  asserted  can  be  back-fitted  to 
earlier  electronic  cross-har  switches)  is  claimed  to  be  able  to  process 
call  requests  three  times  faster  than  previous  switches.  This  tech- 
nology offers  a potential  base  for  providing  ’’fast”  circuit  switching 
to  data  subscribers. 


/ 
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FIGURE  30.  1975  Tentative  Digital  Data  System  Network 


TABLE  13.  ILLUSTRATIVE  RATES  (Ref.  2) 


Interexchange  channel  pricing  is  the  airline  mileage  between  rate  centers  as  shown  in  FCC  Tariff 
255.  The  rates  apply  for  each  section  of  interexchange  channel,  i.e.,  between  the  rate  centers  of 
each  pair  of  service  points. 


Rate  Per  Airline  Mile  Per  Month 


2,400  bits  per  second 

First  25  miles  (0-25) 

$ 1.00 

Next  75  miles  (26-100) 

.90 

Next  150  miles  (101-250) 

.80 

Next  250  miles  (251-500) 

.65 

All  over  500  miles 

.40 

4,800  bits  per  second 

First  25  miles  (0-25) 

1.65 

Next  75  miles  (26-100) 

1.50 

Next  150  miles  (101-250) 

1.35 

Next  250  miles  (251-500) 

1.10 

All  over  500  miles 

.65 

9,600  bits  per  second 

First  25  miles  (0-25) 

3.00 

Next  75  miles  (26-100) 

2.70 

Next  150  miles  (101-250) 

2.40 

Next  250  miles  (251-500) 

1.95 

All  over  500  miles 

1.20 

56,000  bits  per  second 

First  25  miles  (0-25) 

15.00 

Next  75  miles  (26-100) 

13.50 

Next  150  miles  (101-250) 

12.00 

Next  250  miles  (251-500) 

10.00 

All  over  500  miles 

6.00 

Service  Terminals: 

Monthly  Charge 

Per  Service  Terminal 

2,400  bits  per  second 

S 60 

4,800  bits  per  second 

$ 80 

9,600  bits  per  second 

S 80 

56,000  bits  per  second 

$100 

Data  Service  Unit: 

Per  DSU  (All  Speeds) 

S 15 

Multi-Station  Charge: 

Per  Station  on  the  circuit 

$ 20 

Analog-Digital  Connection  Charge: 

Per  Connection 

2,400  bits  per  second 

$100 

4,800  bits  per  second 

$200 

9,600  bits  per  second 

$200 

56,000  bits  per -second 

$200 
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date  AT&T  will  offer  a switched  DDS  capability.  The  time  frame  for 
introduction,  the  technical  characteristics , and  the  cost  schedule  for 
switched  DDS  cannot  but  have  profound  effects  on  data  network  planning. 
The  current  lack  of  information  as  to  future  DDS  services,  especially 
switched  services,  introduces  considerable  uncertainty  in  planning 
future  teleprocessing  systems. 

The  DDS  transmission  system,  as  is  the  conventional  telephony 
plant,  is  composed  of  two  major  segments:  the  local  distribution  or 
access  loops  and  long-haul  transmission.  The  data  subscriber  pro- 
vided here  is  located  on  a T-l  carrier  route  and  will  be  able  to  di- 
rectly access  the  DDS  through  a digital  interface  unit.  The  T-l 
carrier  system  is  a local-area,  digital,  very- high- speed  transmission 
system  originally  designed  for  digitized  (PCM)  voice.  The  T-l  car- 
riers employ  basic  capacity  units  of  1.5  Mbps.  PCM  voice  and  data 
channels  are  time-division  multiplexed  onto  the  T-l  carrier.  Data 
channels  are  available  in  multiples  of  2.4  kbps--the  slowest  data 
speed  offered. 

Long-distance  transmission  in  DDS  can  be  provided  in  either  of 
two  basic  ways.  The  conventional  method  is  to  utilize  available 
wideband  analog  facilities  with  high-speed  modems  to  carry  the  digi- 
tal data  much  as  it  is  done  today.  A new  method  of  transmission, 
data  under  voice*  (DUV) , makes  additional  utilization  of  the  exist- 
ing microwave  radio  relay  facilities.  Advantage  is  taken  of  excess 
power  margin  and  available  spectrum  in  the  existing  microwave  radio 
relay  system.  The  digital  (sub)carrier  is  frequency  multiplexed 
between  the  microwave  carrier  center  frequency  and  the  frequency  of 
the  lowest  telephone  channel  in  the  trunk  group.  (The  unique  robust- 
ness of  the  digital  signal  to  nonlinear  induced  self- interference 


Future  transmission  media  under  active  research  include  millimeter 
wave  cables  and  optical  fibres  which  offer  the  potential  for  pro- 
viding digital  carrier  capacity  up  to  a gigabit  per  second. 
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allows  utilizing  this  spectral  slot  not  usable  by  the  analog  tele- 
phone channels.)  DUV  provides  the  exceptional  saving  in  acquisition 
cost  as  only  modest  electronic  changes  are  required  to  the  already 
installed  microwave  relay  plant.  This  provides  an  opportunity  for 
providing  DDS  long-haul  services  at  considerably  lower  cost. 

A key  feature  of  the  DDS  will  result  from  the  use  of  the  local 
all-digital  T-l  carrier.  Since  the  T-l  is  all-digital  those  sub- 
scribers located  on  a T-l  route  gain  access  to  the  T-l  carrier  through 
a logical  interface  and  control  unit  rather  than  a modem.  DDS  sub- 
scribers will  have  available  for  use  a self- synchronous  data  line  with 
a minimum  speed  of  2.4  kbps.  Moreover,  the  multiplexing  of  integral 
units  of  2.4  kbps  can  be  provided  by  the  carrier. 

The  principal  initial  functional  impact  of  DDS  will  follow  from 
reductions  in  data  transmission  costs  with  improved  transmission 
quality.  Just  as  with  lower  rates  from  Specialized  Carriers  and  the 
new  AT&T  Hi/Lo  tariff  (if  approved),  existing  teleprocessing  networks 
will  be  strongly  motivated  to  topologically  reconfigure  in  order  to 
take  economic  advantage  of  reductions  in  transmission  cost.  The  new 
technical  features  of  DDS  will  have  a lesser  initial  impact  on  ex- 
isting teleprocessing  systems.  A combination  of  increased  ADP  work- 
load and  cost  reductions  in  advanced  terminals  will  pace  modifying 
existing  teleprocessing  systems  in  order  to  fully  utilize  the  DDS 
technical  capabilities. 

On  the  other  hand,  teleprocessing  systems  and  data  networks  in 
planning  or  under  development  will  be  more  strongly  influenced  by 
DDS.  The  synchronous  higher  line  speed  with  lower  error  rate  will 
impact  principally  on  the  access-line  interfaces  of  terminals,  con- 
centrators, and  com  front  ends  ultimately  affecting  their  hardware 
architecture,  capacity,  and  software.  Interfaces  with  long-haul 
wideband  trunks  will  not  be  impacted  as  strongly  as  they  already 
tend  to  be  synchronous  high-speed  facilities.  The  DDS  will  affect 
design  of  common-user  networks,  such  as  the  VANs  and  AUTODIN  II, 
principally  at  the  network  access  nodes  where  both  DDS  and  conven- 
tional access  lines  will  be  terminated. 
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Of  even  greater  potential  significance  to  the  future  development 
of  teleprocessing  systems  and  common-user  networks  would  be  the  in- 
troduction of  data  switching  features  to  the  DDS.  In  effect,  a 
switched  DDS  would  be  providing  a common-user  data  network  and  thus 
could  be  competitive  to  the  VANs.  Utilization  of  a switched  DDS  is 
so  strongly  dependent  on  the  cost,  availability,  and  especially  the 
performance  characteristics  of  the  switching  service  to  be  provided 
that  its  full  impact  cannot  be  projected  (fast  circuit,  virtual  cir- 
cuit, packet,  hybrid,  etc.).  Aside  from  affecting  network  configura- 
tion and  organization,  the  most  immediate  impact  of  a switched  DDS 
would  be  on  the  design  and  usage  of  concentrators  and  com  front  ends. 
These  qualitative  effects  hold  for  any  common-user  switched  data  net- 
work but  take  on  added  qualitative  emphasis  when  considering  such  a 
service  offering  from  AT&T. 

There  does  not  appear  to  be  any  technical  impediment  to  pro- 
viding a switched  DDS  although  doing  so  may  not  accord  to  AT&T  policy 
or  marketing  strategy.  Lack  of  any  written  indication  on  the  part  of 
AT&T  to  even  provide  any  switched  services  on  the  DDS  (or  any  other 
Bell  System  data  transmission  services)  is  perhaps  the  most  relevant 
current  fact. 

d.  Device  Technology.  Since  communications  processors,  e.g., 
concentrators  and  front  ends,  are  specialized  versions  of  computer 
processors,  they  will  be  affected  in  much  the  same  manner  as  dis- 
cussed in  Appendix  B.  The  signal  processing  and  control  elements 
(as  opposed  to  power  supply  and  amplification)  of  modems  are  also 
exhibiting  an  accelerating  use  of  digital  implementation  to  take 
economic  advantage  of  large-scale  integration  (LSI)  technology.  A 
logical  outcome  of  such  a trend  would  be  the  direct  incorporation  of 
the  modem  function  into  new  terminal,  com  front  end,  and  concentrator 
(or  ’’switch")  designs.  The  development  in  microprocessors  and  active 
memories  will  also  maintain  the  progress  toward  smart  terminals  at 
lower  cost,  i.e.,  terminals  with  resident  memory  and  logic  capability. 
Nonpermanent  display  technology  for  terminals,  especially  alphanumeric 


displays  using  plasma,  liquid  crystal,  or  light-emitting  diode  tech- 
nology, is  expected  to  support  the  trend  toward  lower  cost/higher 
performance  terminals.  On  the  other  hand,  significant  cost  reductions 
in  high-performance  permanent- copy  devices  (e.g,,  printers,  cards, 
tape)  are  not  expected. 

Perhaps  one  of  the  most  significant  potential  areas  of  technology 
impact  is  in  switching.  The  general  trend  toward  supplanting  general- 
purpose  processors,  with  software,  replicating  specialized  hardware 
and  firmware , would  appear  to  be  very  applicable  to  the  functional  re- 
quirements of  switching,  whether  packet,  circuit  or  hybrid.  Discus- 
sion of  the  use  of  arrays  of  microprocessors  and  active  memories  for 
configuring  data  switches  has  not  appeared  in  the  literature.  To 
date,  data  switches  described  in  the  literature  have  been  developed 
out  of  the  minicomputer  technology  which  conceptually  and  functionally 
emulates  (in  the  small)  a late  third- generation  computer.  Since 
switching  implies  repetitive  processing  of  input  and  output  arrays, 
fundamentally  new  data-switch  architecture  and  design,  based  on  LSI 
and  new  memory  technology,  would  appear  likely.  This  is  discussed 
further  in  Section  VII- C. 

B.  SUMMARY 

The  trend  in  ADP  technology  (Appendix  B)  clearly  points  toward 
lower  equipment  costs.  Since  there  are  no  indications  of  a trend  to 
lower  software  development  costs,  a shift  in  emphasis  to  use  more  spe- 
cialized hardware  for  firmware  in  systems  may  develop.  This  trend  can 
coexist  with  the  familiar  general-purpose  approach  to  processing.  It 
is  not  at  all  clear  as  to  what  the  balance  between  these  two  trends 
will  be.  The  role  of  centralized  versus  decentralized  processing  is 
of  primary  interest  to  data  networks.  It  seems  likely  there  will  be 
both  centralized  computer  centers  and  distributed  processors;  however, 
the  functions,  tasks,  and  interactions  between  the  two  will  dominate 
future  data  communications.  Projections  to  date,  such  as  those  in 
Refs.  1 and  2,  tend  to  be  conservative  being  based  on  the  accumulated 


ADP  experience  to  date.  Major  new  ADP  user  developments  are  sure* 
to  occur  but  high-confidence  predictions  as  to  their  nature  cannot 
as  yet  be  made.  It  appears  that  we  are  once  again  in  a major  gener- 
ational period  of  ADP  change  (third  to  fourth).  However,  it  is  un- 
likely that  as  in  the  past  the  newest  generation  (fourth)  will  dis- 
place the  previous  equipment.  Networks  will  have  to  support  both 
generations  concurrently. 

The  current  communications  environment  is  dominated  by  the 
characteristics  of  the  existing  analog  telephony  transmission  plant 
and  the  tariff  structure  of  the  Common  Carriers.  Terminals,  modems, 
and  specialized  small  computers  (i.e.,  concentrators  and  com  front 
ends)  have  evolved  for  use  with  the  Common  Carrier  transmission  plant 
to  configure  a data  communication  network  as  a component  of  a specific 
teleprocessing  system.  New  Specialized  Carriers  are  being  encouraged 
to  offer  communication  services  by  perceived  market  opportunities  and 
a regulatory  policy  favorable  to  developing  market  competition.  The 
principal  immediate  effects,  already  manifest  in  the  new  AT&T  Hi/Lo 
density  tariff  changes,  will  be  accelerated  changes  in  both  the  tariff 
rate  and  structure  for  data  transmission.  Changes  in  the  communica- 
tion pricing  structure  in  and  of  itself  create  considerable  motivation 
for  existing  teleprocessing  systems  to  reconfigure  their  communica- 
tion networks  in  order  to  exploit  reduced  costs. 

A class  of  Specialized  Carriers,  the  VANs,  are  proceeding  with 
development  of  subscriber-oriented  common-user  switched  data  networks 
bused  on  adding  special  nodal  facilities  to  leased  dedicated  trans- 
mission facilities  from  the  carriers.  With  one  exception,  TYMNET, 
the  other  VANs  (TELENET,  PCI,  GRAPHNET,  etc.)  to  varying  degrees 
are  derived  from  ARPANET  packet- switched  technology  and  are  just 


The  sweeping  effects  of  the  personal  calculators  and  "smart"  measure- 
ment instrumentation  based  upon  microprocessor  technology,  not  to 
mention  Point  of  Sale  systems,  support  this  assertion. 
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beginning  operations.  Consequently,  connection  interface  standards, 
geographic  coverage,  and  tariff  cost  schedules  are  still  evolving. 

The  TYMNET  network,  having  several  years  of  operational  experience, 
provides  packet  transmission  with  a switching  concept  that  emulates 
the  characteristics  of  circuit  switching  and  yet  obtains  dynamic 
sharing  (statistical  multiplexing)  of  the  transmission  circuits. 

The  introduction  of  the  new  Bell  System  DDS  facilities  utilizing 
T-l  local  carriers  and  data  under  voice  (DUV)  with  only  leased  point- 
to-point  service  (no  data  switching)  can  be  expected  to  further  the 
trend  toward  restructured  transmission  tariff  charges.  The  all-digital 
nature  of  the  T-l  carrier  providing  a considerably  enhanced  synchro- 
nous base-band  data  transmission  service  is  consonant  with  the  trend 
toward  smart  terminals  and  improved  computer  com  front  ends.  Of  even 
greater  significance  would  be  the  introduction  in  the  near  future  of 
switched  service  on  the  DDS.  Since  a switched  DDS  would  provide  a 
pervasive  subscriber-oriented  common-user  data  network  of  considerable 
geographic  coverage  and  capacity,  it  would  have  major  impact  on  the 
general  competitive  evolution  of  the  data  communications  market,  user 
teleprocessing  planning  activities,  and  the  course  of  technology  de- 
velopment, both  hardware  and  software.  To  date,  the  possibility  of 
DDS  switched  service  is  speculative.  As  yet,  there  has  been  no  in- 
dication by  AT&T  that  introduction  of  switched  service  for  the  DDS 
is  planned,  let  alone  the  nature  of  the  technical  characteristics 
of  such  service  (e.g.,  fast  circuit,  store-and- forward , hybrid). 

The  computer  driven  technologies  in  circuits , memories , and  dis- 
plays will  generate  strong  economic  pressures  toward  the  production 
of  the  conversion  to  lower  cost  smart  terminals  (or  terminal  "systems1' ) 
with  enhanced  processing  and  memory  capabilities.  This  will  further 
the  overlap  between  and  blur  the  conventional  separation  of  function 
and  equipment.  Of  special  interest  is  the  potential  impact  of  the 
rapidly  emerging  hardware  technology  and  cost  trends  on  developing 
new  concepts  of  data  switches.  Current  packet  and  (electronic)  circuit 
switch  design  concepts  considerably  predate  the  evolving  microprocessor 
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and  active  memory  technologies.  Conceptually,  new  approaches  in  data 
swtich  design  with  a hardware  as  opposed  to  software  emphasis  would 
be  timely,  especially  for  a mixed  circuit/packet  function. 

Overall,  the  future  communications  environment  is  characterized 
by  uncertainty.  The  competitive  outcome  of  new  types  of  service, 
their  geographical  extent,  and  the  economic  viability  of  the  supplier 
cannot  be  predicted.  Although  the  trend  in  communication  transmission 
costs  is  downward,  the  specifics  in  structure  and  rates  are  not  clear. 
Introduction  in  the  future  by  AT&T  of  switched  service  in  the  DDS 
could  have  a profound  impact  on  the  development  of  teleprocessing 
technology  and  balance  between  dedicated  and  common-user  networks. 


VII.  SELECTED  SYSTEM  RED  ISSUES  AND  NEEDS 


In  the  previous  sections,  numerous  design  and  evaluation  issues 
have  been  raised  that  relate  to  teleprocessing  data  networks.  The 
purpose  of  this  section  is  to  bring  these  together  and  to  provide 
suggestions  for  technical  activities  relating  to  subscriber-oriented 
data  networks  to  aid  in  the  development  of  a coordinated  research  and 
development  effort  within  DoD. 

A.  REQUIREMENTS,  ACTIVITY  MODELING,  AND  SYSTEM  EVALUATION 

In  Section  IV,  the  requirements  formulation  within  DoD  was  re- 
viewed and  inadequacies  revealed  that  pertain  to  design  of  teleprocess- 
ing systems.  As  more  comprehensive  data  describing  user  ADP  tasks  or 
functions  are  made  available,  it  will  be  necessary  to  translate  these 
needs  into  technical  specifications  of  generic  types  of  basic  process- 
ing and  data  transmission  functions  and  to  relate  these  to  communi- 
cations requirements  and  network  organization.  In  order  to  achieve 
this  translation,  mathematical  models  relating  user  activity,  com- 
puter actions,  data  organization,  and  resulting  communication  traffic 
will  have  to  be  developed  or  refined.  Not  only  are  such  models  of 
direct  use  in  design  of  specific  systems  but  they  can  have  significant 
bearing  on  aggregating  users  into  networks.  Moreover,  such  models 
will  be  necessary  in  the  design  of  meaningful  test  and  evaluation 
procedures  for  data  networks  and  interpreting  their  results  for  sub- 
scriber implications. 

The  current  probabilistic  descriptions  of  data  (e.g.,  message 
occurrences--Poisson,  message  length- -geometric,  component  reaction 
times--exponential,  etc.)  are  guided  by  what  appear  to  be  physically 
plausible  and  mathematically  tractable.  There  have  not  been  collected 


k- 


I 


any  extensive  real  data  on  the  statistics  of  system  use  and  perform- 
ance (excepting  Refs.  68  and  69  which  repoi't  on  data  statistics  for 
a single  paired  compute!  remote- terminal  connection).  Prior  to  the 
acquisition  of  concrete  data  and  during  the  initial  development  phase 
of  any  pioneering  technical  activity,  one  has  no  recourse  but  to 
postulate  idealized  models.  However,  it  is  reasonable  now  to  con- 
sider how  more  realistic  models  can  be  developed  and  experimental 
data  obtained. 

Along  with  a needed  capability  to  relate  user  ADP  task  require- 
ments to  teleprocessing  functions  and  data  traffic  flow,  there  is  a 
broader  need  to  develop  capability  for  evaluating  system  performance. 
Hopefully,  the  mathematical  disciplines  and  methods  useful  to  system 
evaluation  will  bear  considerable  similarity  to  those  used  for  traffic 
modeling.  In  the  development  of  an  evaluation  theory,  it  will  be  neces- 
sary to  identify  key  parameters  or  measures  of  performance  (there  are 
many  potentially  useful  measures)  and  discover  their  characteristics 
and  the  relationships  between  measures.  For  example,  measures  may 
exist  which  in  effect  are  equivalent.  It  is  of  use  to  discover  what 
these  are  and  what  "equivalent"  means.  Currently,  performance  is 
measured  by  criteria  (e.g. , channel  miles,  response  time,  buffer  re- 
quirements, ADP  task  throughput)  chosen  by  the  owner,  user  or  analyzer 
of  a particular  system  according  to  the  dictates  of  his  system  con- 
figuration and  his  specific  interest  or  even  in  an  ad  hoc  manner. 
Further,  performance  is  predicted  based  in  many  cases  on  simulation 
as  well  as  mathematical  analysis.  Consequently,  comparisons  between 
like  syst  ms  (what  are  like  systems?)  are  difficult. 

A further  consideration  is  the  need  to  obtain  standard  methods 
of  describing  requirements  and  systems  performance  to  support  major 
policy  formulation  and  decision  making  at  higher  management  levels. 

One  of  the  principal  potential  benefits  afforded  by  teleprocessing 
capabilities  is  the  opportunity  to  reaggregate  ADP  tasks  and  func- 
tions in  order  to  reduce  costs  and/or  manning.  An  important  corollary 
benefit  of  a requirement  methodology  would  be  to  help  standardize 
utilization  reporting  profiles  from  the  diverse  ADP  activities. 
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B.  DATA  INTERFACE  STANDARDS 
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1.  Introduction 

1 

A key  problem  in  data  communications  is  the  interface  (electri- 
cal, transmission,  logical)  between  the  data  user  end  points  (ter- 
minals, computers)  and  the  communication  media.  An  intimately 
associated  problem,  which  is  sometimes  subsumed  under  the  interface 
problem,  is  the  method  of  access  by  a remote  user  (terminal  or  other 
computer)  to  a computer  and  the  control  of  that  access.  Those  sys- 
tems which  use  dedicated  transmission  facilities  or  the  dial-up  voice 
band  circuits*  of  the  Common  Carriers  have  available  to  them  consid- 
erable flexibility  in  solving  these  functional  problems. 

The  attractiveness  or  acceptability  of  a common-user  network  by 
a potential  subscriber  will  be  heavily  weighted  by  the  relative 
"transparency”  as  perceived  by  the  subscriber  of  the  network.  The 
common-user  data  network  tends  to  reduce  the  interface  and  control 
flexibility**  available  with  dedicated  or  dial-up  circuits.  The 
subscriber’s  interest  in  a common-user  network  is  solicited  by  the 
reduced  communication  costs  and  wider  degree  of  connectivity  to  other 
subscribers  offered  by  the  network.  The  viability  of  a common-user 
switched  communication  network  is  heavily  dependent  on  adopting  a 
uniform  and  widely  accepted  set  of  network/subscriber  data  and  pro- 
cedural interface  standards  and  access  control  mechanisms  that  do 
not  incur  unacceptable  economic  or  performance  penalties.  The  access 
control  and  interface  standards  utilized  can  have  heavy  impact  on  sub- 
scriber hardware,  software  and  task  or  applications  performance  (e.g., 
job  throughput,  interactive  terminal  response  time).  Subscriber 
utilization,  in  return,  has  direct  effect  on  network  design,  internal 
control,  and  growth. 


To  date  this  represents  the  vast  majority  of  implemented  systems. 
The  ARPANET  and  VAN  represent  a new  departure. 

A current  example  of  this  restriction  is  provided  by  the  control 
complexity  of  a polled  access  line. 
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2 . Current  Context 


Motivated  by  a desire  to  connect  as  wide  a variety  of  terminals 
to  available  computers  as  possible,  industry  has  strong  incentives 
to  adopt  certain  standards  (more  accurately  a limited  set  of  differing 
standards).  The  present  standards  are  all  characterized  as  having 
evolved  in  the  context  of  dedicated  or  dial-up  circuit  transmission 
facilities.  These  standards  have  dealt  with  various  transmission 
speeds,  modulation  waveforms,  half-  or  full-duplex  lines,  synchronous 
or  asynchronous  terminals  (modems),  error  control,  and  direct  or  polled 
access  lines.  In  addition,  various  definitions  of  alphanumeric  charac- 
ter (bit  code)  and  data  format  and  structure  have  been  specified.  Con- 
sidering the  wide  variety  of  end  user  equipments  with  the  multiplicity 
of  communication  transmission,  several  differing  sets  of  standards 
have  evolved  with  the  terminal  manufacturers  attempting  to  incorporate 
within  their  equipments  as  great  a flexibility  as  possible  to  adapt* 
to  the  various  standards  utilized.  An  excellent  guide  to  the  current 
existing  standards  is  provided  in  Ref.  70. 


Generally  speaking,  the  standards  evolved  to  date  do  not  emphasize 
a careful  differentiation  between  the  subscriber  end-point  control  and 
the  transmission  path  control  (i.e.,  computer  and  terminal  logic  in- 
teraction as  differentiated  from  the  interaction  between  transmission 
path  and  terminal  or  computer).  Emphasis  on  this  distinction  has  not 
been  necessary  in  the  current  communications  context  provided  by  dedi- 
cated or  dial-up  telephone  facilities.  Line  and  end-point  control, 
as  well  as  the  interface,  have  been  the  responsibility  of  the  individ- 
ual teleprocessing  system  and  allow  the  greatest  flexibility  in  im- 
plementing the  interface  and  control  most  suitable  to  a specific  sys- 
tem. On  the  other  hand,  this  flexibility  seriously  restricts  the 
ability  to  cross- connect  computers  and  terminals  from  differing  sys- 
tems as  well  as  tending  to  capture  an  evolving  system  to  a product  line. 

TT  — — ' 

In  many  cases,  at  time  of  customer  delivery,  a terminal  has  a fixed 
interface  module  installed  matched  to  the  standards  prevalent  on 
the  purchaser's  system. 
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For  dedicated  point-to-point  transmission,  the  communication 
supplier  provides  a permanent  line-connect  of  stated  speed  and  quality 
between  designated  points.  For  dial-up  service,  the  Common  Carrier 
additionally  provides  the  usual  signaling  and  supervisory  services 
for  switched  telephony,  such  as  routing,  destination  ringing,  busy 
signal,  and  circuit  completion  disconnect.  Present  centralized  tele- 
processing systems  with  tight  integration  between  their  computer  and 
terminal  equipment  provide  the  following  types  of  functions: 

• Electrical  interface  with  the  line 

• Verification  of  presence  and  status  plus  conduct  of  logic  dia- 
logue between  line  end  points  including  send/receive  protocols 

• Maintenance  of  end-to-end  bit  or  character  error  control 
and  framing 

• Provision  of  recovery  mechanisms  for  logic  error  states 

• Monitoring  of  facility  status. 


Additional  functions  are  required  when  a basic  transmission  path  is 
shared  by  several  to  many  users  in  an  attempt  to  reduce  their  communi- 
cations cost.  This,  typically,  is  exemplified  by  polled  lines;  that 
is,  a long  string  of  terminals  shares  a single  "party"  line  and  a 
master  station,  usually  a computer,  controls  the  access  and  "conversa- 
tion" of  the  sharing  terminals  with  a variety  of  round-robin  polling 
techniques.  Another  typical  method  of  sharing  transmission  facili- 
ties is  with  the  use  of  a concentrator.  Here  the  sharing  terminals 
are  connected  by  (usually  individual)  short  "local"  paths  to  the 
concentrator,  a relatively  complex  device  (small-  to  medium- size 
specialized  computer),  which  then  multiplexes  the  terminals  on  a 
demand  basis  to  dynamically  share  the  long-distance  communications 
path.  This  arrangement  reduces  the  interface  and  control  as  seen 
by  an  individual  terminal  to  that  of  a direct  local  access  path  to 
a computer  since  the  concentrator  on  the  terminal  side  emulates  a 
computer  input.  On  the  other  hand,  a new  set  of  control  and  data 
protocol  requirements  is  generated  to  interconnect  the  concentrator 
with  a computer. 
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Differentiated  from  transmission  path  control  (i.e.  , signaling 
and  line  supervision),  the  data  transmission  standards  that  have 
evolved  to  date  can  be  categorized  as  follows; 

1.  Definition  of  Transmission  Path  Characteristics 

• Point-to-point,  multipoint,  half  or  full  duplex 

• Line  speed,  quality 

• Waveform  modulation,  synchronization 

2.  Data  Structure 

• Character /bit  code 

• Frame  or  block  structure,  header,  text,  end 

3.  Logical  Sequence  Structure 

• Send/receive  protocol  (including  polling  technique) 

• Transmission  error  control 

• Logic  error  recovery 

Category  1 relates  to  transmission  lines  and  modems;  category  2 deals 
with  common  interpretation  of  data  bits ; and  category  3 deals  with 
common  logical  procedures.  To  date,  category  3 has  the  least  compre- 
hensive and  widely  accepted  set  of  standards.  Category  3 exemplifies 
the  dilemma  of  customizing  a design  to  achieve  efficiency  and  per- 
formance versus  standardization  to  allow  widespread  interoperability 
between  subsystem  components. 

3.  ADCCP  Example 

An  example  data  standard  which  is  illustrative  of  the  relation- 
ship between  categories  2 and  3 above  is  the  ANSI- proposed*  Advanced 
Data  Communication  Control  Procedure  (ADCCP).  The  ADCCP  defines  a 
data  structure  which  is  relatively  independent  of  category  1.  Given 
an  acceptable  transmission  of  raw  bits,  ADCCP  groups  these  bits  into 
variable  length  frames  with  the  following  structure; 

• Frame  start  (flag)  of  a standard  fixed  pattern  of  eight  bits 

• An  address  block  of  eight  variable  bits  (hence  no  more  than 

2^  = 256  addresses,  less  with  redundancy  for  address  protection 

• A control  block  of  eight  variable  bits 

* 

This  standard  has  not  yet  been  adopted  for  international  use  although 
it  has  been  under  intensive  development  and  consideration  for  several 


• A text  block  of  variable  length 

• A frame  check  block  of  16  bits  for  error  control 

• An  end- frame  flag  of  eight  bits  identical  to  the  frame  start 
flag 

• A standard  text- scanning  and  bit- stuffing  procedure  for  prevent- 
ing a text  bit  pattern  identical  to  the  flag  from  indicating  an 
erroneous  frame  end. 

In  addition,  the  ADCCP  standard  delineates  a specific  set  of  con- 
trol block  bit  codes  and  logic  procedures  for  controlling  the  dialogue 
between  terminal  and  computer  including  the  functions  listed  in  cate- 
gory 3.  IBM  has  announced  adoption  of  a new  data  standard,  Synchronous 
Data  Link  Control  (SDLC) , v\hich  is  formatted  the  same  as  ADCCP  (Ref.  71). 
However,  the  SDLC  control  block  and  logic  procedures  may  differ  from 
ADCCP  in  error  control  and  polling  procedure.  This,  in  turn,  could  af- 
fect the  terminal/computer  interface  and  throughput  performance. 

The  ADCCP  and  SDLC  interface  standards  are  the  result  of  an  evo- 
lutionary process  of  major  improvements  in  data  terminal  technology 
taken  within  the  context  of  autonomous  centralized  computer  facilities 
utilizing  the  Common  Carrier  telephony  plant.  The  newer  terminals  uti- 
lize data  buffers  which  permit  the  more  efficient  transmission  of  data 
blocks  as  opposed  to  the  older  technique  of  character- by- character 
transmission.  The  frame  error  control  procedures*  and,  for  polled 


The  error  control  is  end-to-end  and  utilizes  the  frame  error  control 
block  to  detect  any  errors  in  the  frame.  If  an  error  is  detected,  a 
request  is  made  to  retransmit  the  frame.  Thus,  in  addition  to  the 
minimal  buffer  memory  needed  by  a terminal  to  accumulate  each  frame , 
the  largest  need  for  memory  space  is  dictated  by  the  requirement  to 
hold  the  already  transmitted  frame  in  storage  against  the  contingency 
of  an  error  upon  reception.  There  are  a variety  of  retransmission 
strategies , all  of  which  involve  a trade  between  terminal  complexity 
and  throughput.  A common  strategy,  which  is  one  of  the  simplest  in 
buffer  management,  is  to  keep  sending  indexed  data  frames  without  wait- 
ing for  acknowledgment  of  correct  reception.  When  a received  error 
causes  a request  for  retransmission  of  a specific  frame,  the  trans- 
mitter indexes  back  to  the  requested  frame  and  retransmits  that  frame 
and  all  succeeding  frames  whether  received  correctly  or  not.  This 
simplifies  terminal  buffer  organization  and  management  at  a loss  of 
throughput  (retransmission  of  correct  frames). 
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lines,  the  polling  procedures  have  significant  impact  on  the  organiza- 
tion, sizing,  and  management  of  these  terminal  data  buffers,  and  this 
affects  the  performance  of  the  terminal  and  communications  throughput. 
Master  control  of  the  terminal  usually  resides  in  the  computer  facility 
(or  concentrator). 

4.  Network/Subscriber  Interface 

It  is  through  the  concentrator  approach  that  the  commercial  time- 
sharing computer  service  companies  provide  a common-user  service  be- 
tween subscribing  terminals  and  the  computer  facility  (Ref.  21).  In 
this  regard,  the  common-user  interface  is  between  the  terminals  and 
concentrator.  The  rest  of  the  system--computers , concentrators,  and 
long-haul  communications- -is  under  the  control  and  direction  of  the 
computer  facility  as  an  integral  whole.  Here  the  communications  are 
an  essential  component  of  the  teleprocessing  system  for  which  the 
computer  facility  is  the  focus  of  the  system.  A common-user  communi- 
cation network,  such  as  ARPANET  and  the  VAN,  takes  the  additional  step 
of  making  the  computer  a subscriber  to  the  network,  separating  the 
computer  facility  from  its  dominant  role  over  its  communications  sup- 
port. This,  then,  generates  the  need  for  consideration  of  a new 
interface  dimension — that  between  the  computer  as  a subscriber  and 
the  network. 

It  is  not  clear  as  to  the  degree  to  which  standards  for  the 
computer /network  interface  can  be  established  separately  from,  or 
identical  to,  the  terminal/network  interface.  A basic  issue  to  be 
examined  for  the  common-user  network  is  the  interface  standard  archi- 
tecture. Can  a single  common  overall  network  interface  standard  for 
both  terminals  and  computers  be  implemented  which  is  efficient  and 
economically  acceptable  to  potential  subscribers,  or  is  a more  complex 
hierarchical  set  of  standards  required  which  differentiates  between 
computers  and  terminals?  In  this  context,  the  functions  of  network 
access  and  transmission  path  control  must  be  differentiated  from 
subscriber  end-point  control. 


As  an  example,  any  fast  store-and-forward  type  of  common-user 
•data  network  (e.g.,  ARPANET- derived  networks)  has  the  potential  for 
overlapping  responsibilities  with  ADCCP/SDLC  type  standards  in  at 
least  the  following  areas: 

• Addressing 

• Start/stop  control  (especially  for  polled  lines) 

• Error  control 

• Failure  recovery. 

The  separation  and  coordination  of  responsibilities  between  the  net- 
work and  subscriber  must  be  given  study.  For  example,  independent 
of  the  subscriber,  store-and-forward  switching  must  utilize  error- 
control  and  retransmission  techniques  internal  to  the  data  network. 
Thus,  important  considerations  are  requirements  for  subscriber- 
maintained  error  checking  and  resulting  interaction  with  the  network. 

Either  or  both  of  the  ADCCP  and  SDLC  interface  standards  can  be 
expected  to  be  widely  utilized  in  the  future  by  ADP  manufacturers . 

It  is  extremely  important  that  interface  standards  and  access  con- 
trol for  a DoD  common-user  subscriber-oriented  communication  net- 
work (such  as  the  AUTO DIN  II  concept)  be  thoroughly  examined  for 
the  degree  of  compatibility  with  ADCCP  or  SDLC  and  to  identify  re- 
sulting design  features  and  performance  factors  which  have  impact 
both  on  subscriber  and  network  operation.  In  Ref.  72  an  initial 
examination  of  these  issues  was  undertaken  for  WWMCCS  computer  net- 
working. 

The  principal  areas  of  concern  with  regard  to  overlapping  sub- 
scriber and  network  control  responsibilities  for  any  common-user  data 
network  would  appear  to  be  in  error  control  and  failure  recovery.  If 
polled  terminal  access  lines  are  used  to  connect  to  the  common-user 
network,  then  start/stop  control  would  also  be  a primary  concern. 
These  control  functions  have  time-dependent  logic  activities  between 
subscriber  end  points  (computer  and  terminals)  and  subscriber/network 
access  interface.  Some  of  the  deleterious  effects  that  could  develop 
are  as  follows: 


167 


1. 


Blocked  logic  states  at  subscriber/network  interface 
and  between  subscriber  end  points. 

2.  Enlarged  and/or  more  complex  data  buffering  in  both 
subscriber  terminals  and  network  access  points. 

3.  Increased  traffic  loading  to  network  especially  erratic 
peaking  packet  flow  leading  to  network  overloading, 
possibly  to  switch  blocking. 

4.  Reduced  useful  throughput  to  subscribers. 

5.  Distress  to  subscriber  software. 

The  addressing  function  is  of  secondary  impact  in  that  it  essentially 
adds  redundant  bit  overhead  to  the  subscriber  which  reduces  the  ef- 
fective transmission  rate.  However,  it  must  be  assumed  that  logic 
conflicts  in  addressing  are  avoided. 

The  problem  of  relatively  transparent  communications  to  tele- 
processing systems  is  quite  complex  and  varies  with  different  system 
specifics.  The  interface  and  control  issues  have  great  impact  on 
individual  subscriber  hardware  configuration  and  software  as  well  as 
on  system  utilization  factors  and  performance.  There  is  a fundamental 
need  to  explore  the  relationships  of  data  integrity,  system  control, 
and  economic  performance  between  subscribers  and  a common-user  com- 
munications network  as  a function  of  network  design  and  operation. 

The  objective  of  a common  all-encompassing  subscriber/network  inter- 
face is  to  allow  maximum  interoperability*  between  the  largest  number 
of  subscribers.  This  should  be  compared  to  a reduced  set  of  interface 
standards  which  produce  minimal  impact  on  subscribers**  but  may  incur 


' In  effect  the  network  performs  the  function  of  being  a common 
interface  to  all  its  subscribers. 

This  situation  is  conceptually  typified  by  the  current  use  of  the 
telephony  plant  although  lower  cost  communication  networks  with 
quicker  response  are  desirable. 


loss  of  subscriber  interconnectivity.  The  possibilities  for  a com- 
promise network  design  between  these  extremes  must  be  explored.  If 
no  single  network  is  sufficiently  adequate,  a mix  of  networks  may  be 
required  and  the  principal  elements  of  each  should  be  identified. 

C.  DATA  SWITCHING  TECHNIQUES 

The  development  of  data  switching  technology  (packet,  fast  cir- 
cuit, other)  can  be  expected  to  have  considerable  influence  on  the 
future  evolution  of  teleprocessing  system  components  and  architec- 
ture. The  discussion  here  is  intended  to  provide  preliminary  identi- 
fication, aggregat'on,  and  possible  impact  on  future  data  networks  of 
switching- technology-related  issues . 

In  other  sections  of  this  report,  very  broad  issues  were  raiseu 
in  regard  to  networking  in  relation  to  aggregation  of  users’  require- 
ments to  network  size,  scope,  topology,  capacity,  access,  cost,  con- 
trol, and  standards.  In  these  issues,  switching  technology  plays  an 
important  role.  This  section  only  discusses  the  switching  element. 

In  particular,  "packet”  switching  is  described  and  contrasted  to  cir- 
cuit switching.  The  reader  is  assumed  to  be  familiar  with  the  circuit- 
switching  concept  and  its  employment  in  the  telephone  plant. 

1.  Background 

Data  networks  have  arisen  in  the  commercial  field  to  meet  several 
classes  of  service.  They  have  developed  in  a system- specif ic  manner 
with  very  low  capability  for  system  cross-operability  even  within  a 
similar  class  of  service.  They  have  all  depended  for  their  communi- 
cations on  the  Common  Carrier  telephone  plant. 

As  a result  of  the  tariff  structure  and  technical  characteristics 
of  available  terminals,  most  teleprocessing  systems  sought  better  line 
utilization  for  their  terminal/computer  interconnects  through  the 
use  of  concentrators,  multiplexers,  and  "communications  front  ends" 
(specialized  processor  between  the  computer  and  the  transmission 
lines).  In  order  to  economically  broaden  connectivity,  switching  is 
required.  However,  as  a function  of  the  centralized  ADP  structure 
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of  most  systems  currently  in  operation  (Ref.  23),  a Star-like  topology 
was  adopted  (more  generally,  a Tree  topology)  wherein  switching  is 
implicitly  performed  by  the  multiplexer/concentrator  in  an  essentially 
vertical  flow  of  information  between  terminals  and  the  central  com- 
puter facility. 

When  switching  is  desired,  the  normal  circuit- switch  capability 
of  the  telephone  plant  has  proven  highly  unattractive  to  the  computer 
community.  This  derives  from  the  present  slow  call- setup  time  (5  to 
10  sec)  in  a dial-up  circuit  which,  for  interactive- type  teleprocess- 
ing, is  most  disadvantageous.  With  the  long-distance  tariff,  a cir- 
cuit-switching line  requires  the  switched  path  be  held  for  the  dura- 
tion of  the  call.  Since  such  a call  cannot  be  multiplexed/concen- 
trated, the  line  utilization  is  very  poor,  hence  uneconomical.  This 
has  encouraged  Star-like  systems  with  limited  switching  between  major 
nodes  rather  than  between  terminals. 

With  the  potential  for  overcoming  the  deficiencies  of  circuit 
switching,  the  "packet- switch”  technology  developed  by  RRFR  has  been 
given  considerable  attention.  The  packet  switch,  described  in  what 
follows,  is  capable  of  several  distinctly  different  functions: 

• Provision  and  control  of  access/egress  to  the  network 

• Packet  reassembly 

• Rddressing 

• Concentration  of  traffic 

• Store- and- forward  switching  with  adaptive  routing 

• Error  control 

• Code  converting. 

The  RRPR  necwork  with  the  "IMP"  packet  switch  is  a particular  reali- 
zation of  the  above  functions.  Packet- switched  networks  can  be  con- 
figured differently  (Ref.  11)  from  that  of  the  RRPR  network  (e.g., 
deterministic  routing,  and  hierarchical  switching)  with  different 
allocation  of  functions.  Thus,  it  is  important  to  differentiate  be- 
tween the  access/egress,  multiplex,  concentrate  functions  as  well  as 
the  address,  error  control,  and  routing  functions. 
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Packet  switching  need  not  be  advantageous  for  all  classe-  of 
data  transmission,  especially  ones  involving  bulk  transfer  of  large 
data  volume  over  minutes  to  hours  of  time  (e.g.,  file  transfer). 

Moreover,  for  centralized  Star  networks,  the  pure  switching  function 
requirements  are  minimal  so  that  present  multiplex/concentrator  equip- 
ment is  economic.  On  the  other  hand,  for  interactive  quick- response 
systems  with  a distributed  topology  (computer  and  terminals  not  con- 
nected in  a Tree  structure),  packet  switching  offers  definite  advan- 
tages. In  addition,  packet  switching  can  provide  adaptive  routing 
which,  when  taken  with  a distributed  network  topology,  provides  con- 
siderably enhanced  physical  survivability  for  high- precedence  trans- 
actions. Of  central  interest  is  the  development  of  design  guidelines 
for  matching  teleprocessing  users  to  a network  topology,  capacity, 
and  switching.  Included  should  be  hybrid  packet/circuit  switching 
concepts.  To  date,  no  adequate  "network”  theory  appears  available 
for  analyzing  these  issues. 

2.  Packet  Switching 

Packet  switching  utilizes  the  advanced  development  of  small  multi- 
programmed  minicomputers  to  perform  the  multiplex,  subscriber  inter- 
face, access  control,  concentrate  arid  route /switch  functions.  A packet 
is  a piece  ("quanta")  of  information  with  a beginning  (header)  contain- 
ing administrative  data  (e.g.,  destination,  sequence,  precedence, 
origin,  type  packet,  etc.),  a middle  containing  the  data  up  to  a 
maximum  number  of  bits  (e.g.,  1000),  and  an  end  containing  parity 
check  and  end  bits.  Packets  are  accepted  from  a subscriber  at  an 
access  part  of  a switch  and  sent  on  a store -and -forward  basis  switch- 
to-switch  until  arrival  at  a destination  switch  which  serves  the  ad- 
dressee. Incoming  packets  to  the  packet  switch  are  placed  in  arrival 
queues  whereupon  logic  modules  examine  the  packet  header  for  destina- 
tion and  packet  ending  for  error  check.  If  the  packet  error  check  is 
correct,  the  logic  module  places  the  packet  in  the  appropriate  output 
queue  (routing),  and  informs  (by  a short  packet)  the  transmitting  node 
from  which  the  original  packet  was  received  that  it  has  accepted  re-  ji 


hold  the  packet  in  memory.  If  the  parity  check  were  incorrect,  a 
request  for  packet  retransmission  would  be  made.  Packet  routing  is 
performed  adaptively.  The  packet  at  a transmitting  nodal  switch  is 
routed  over  a transmission  line  in  the  direction  of  its  destination 
However,  with  excessive  line  loading,  an  alternate  node  may  be  se- 
lected according  to  an  ordering  of  next  nearest  in  the  direction  of 
the  destination. 


A packet  thus  makes  its  way  through  the  network  node  by  node. 

In  addition  to  enhanced  survivability,  an  interesting  property  of 
adaptive  routing  is  the  reduced  network  delay  or  flow  sensitivity 
to  the  detailed  traffic  structure  of  each  pair  of  transmitting  and 
receiving  subscribers.  Network  performance  depends  principally  on 
the  sum  of  individual  subscriber  traffic.  It  is  clear  that  the  flow 

is  stochastic  with  node  coupling,  i.e.,  events  at  one  node  affect  j 

those  directly  connected  to  it. 


There  is  a substantial  amount  of  software  supporting  the  packet 
switch.  Self- checking  and  guard  programs  are  required  to  prevent 
memory  overload  and  correct  or  notify  failures.  If  adaptive  routing 
is  used  (as  it  is  in  ARPA  network),  flow  statistics  must  be  exchanged 
between  nodes  so  that  flow  routing  priority  tables  can  be  generated 
pt3«iodically  at  each  node.  In  addition  to  routing  the  transiting 
packets,  there  is  also  software  for  handling  subscriber  packets  en- 
tering and  leaving  the  network.  It  is  here  that  access  control  is 
established  s.nd  subscriber  terminal  concentrating  and/or  multiplexing 

N 

is  performed.  \JJote  that  "trunk"  concentrating/multiplexing  also  can 
be  performed  (e.g~  , combining  several  50-kbps  incoming  trunk  lines 
to  a 224-kbps  output  line). 

The  above  represents  a very  simplified  description  of  the  nodal 
packet-switch  concept.  Considerable  descriptive  design  and  details 
are  available*  relative  to*. 


A series  of  Quarterly  Technical  Reports,  "Interface  Message  Processors 
for  the  ARPA  Computer  Network,"  generated  by  Bolt  Beranek  and  Newman, 
Cambridge,  Mass.  Frank  E.  Heart,  principal  investigator,  submitted 
to  ARPA  and  available  from  Defense  Documentation  Center.  See  Refs. 

28,  73,  and  74. 
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• Access/egress 

(a)  packet  standard  formats 

(b)  protocol  between  accessing  terminals/ 
accessed  node  and  accessed  node/called  node 

(c)  access  control,  e.g.,  precedence,  preempt 

• Concentrating/multiplexing 

(a)  packet  stacking  in  memory  or  access  per  above 

(b)  management  of  input/output  memory  queues 

• Switching/routing 

(a)  routing  tables 

(b)  route  flow  data 

(c)  network  control. 

This  represents  an  outline  of  functions  performed  at  a packet- switching 
node  which  in  turn  must  be  placed  within  a network  topology.  Node 
location  and  capacity  must  be  interconnected  with  a grid  of  trans- 
mission lines  of  suitable  capacity.  Taken  together,  the  nodes  and 
lines  form  the  packet- switched  network. 

Returning  to  the  packet  node , an  extremely  important  item  is  the 
’’capacity”  of  the  node,  i.e.,  its  ability  to  process  bits  per  second 
and  packets  per  second  together  with  the  sizing  of  its  memory.  The 
driving  factors  in  sizing  a packet  node  are  separable  into  the  access/ 
egress  load  (terminals,  host  computers),  the  subscriber  interface 
characteristics  (access  line  speed/error  rate,  synchronous /asynchro- 
nous , polled,  etc.),  and  the  trunk  transmission  line  characteristics 
(speed/error  rate,  transmission  delay  and  average/peak  load  to  con- 
nected neighboring  nodes).  Since  packets  are  held  in  memory  until 
acknowledgment  of  correct  reception  by  the  next  node,  the  summed 
products  of  line  speed  and  transmission  delay  of  a node's  outgoing 
trunks  play  a key  role  in  sizing  nodal  memory.*  [In  this  regard, 


Note  that  should  a node  bog  down,  nodes  sending  to  it  must  be  in- 
formed so  as  to  reject  further  traffic  destined  for  the  overloaded 
node;  otherwise,  propagating  overload  can  occur. 


satellite-relayed  transmission  circuits  provide  special  problems 
with  their  long  transmission  delay  (1/4  sec)  requiring  special  node 
configuration  and  system  software  redesign.] 

The  problem  of  network  topological  design,  node  and  line  loca- 
tion with  the  assignment  of  their  capacities  admits  of  idealized 
analysis  based  upon  the  theory  of  stochastic  flow  on  a graph.  Spe- 
cialization of  this  theory  has  been  developed  and  applied  to  the  de- 
sign of  the  ARPANET  (Ref.  75).  Given  or  postulating  a subscriber 
traffic-flow  matrix,  a tariff  schedule  of  the  Common  Carriers,  and 
node  costs,  a preliminary  network  can  be  laid  out  which  attempts  to 
minimize  cost  for  a specialized  average  or  peak-packet  transmission 
time  through  the  network  (e.g.,  1/2  sec).  Such  analysis  provides  the 
initial  setting  of  the  key  items  of  design,  such  as  line  and  node 
layout  and  line  speed.  (The  network  topology  problem  arises  for  any 
type  of  transmission  and  switching.  Graph  theoretic  flow  analysis  is 
a basic  mathematical  tool  useful  to  this  problem.  However,  specific 
analytic  techniques  will  depend  on  the  type  of  network  desired. ) 

This  then  provides  the  basis  for  the  design  of  each  packet- switching 
node.  The  resulting  node-specific  design,  expected  performance,  and 
cost  can  then  be  reiterated  back  into  the  network  analysis  for  further 
refinement. 

To  date,  the  packet-switched  ARPANET  has  been  implemented  with- 
out any  hierarchical  arrangement  of  the  network  topology.  However,  as 
the  network  has  grown,  it  has  been  realized  that  regionalizing  the 
nodes  (i.e.,  grouping  them  into  clusters)  is  advantageous  in  order 
to  reduce  the  network  housekeeping  data  flow  (overhead)  used  in  com- 
puting the  adaptive  routing  tables.  Motivated  by  the  routing  problem, 
efforts  are  under  way  to  examine  regionalization  for  large  packet- 
switched  networks.  This  would  impose  a hierarchical  structure  on  the 
network. 

The  broadened  concept  of  structured  hierarchical  packet- switched 
data  networks  raises  many  new  and  fundamental  issues  relating  to 
(1)  hierarchical  regional  architecture  and  (2)  routing  and  flow 
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control  within  and  between  regions  and  interregional  interface  stan- 
dards. Specific  regionalized  network  concepts  are  being  advanced  in 
Ref.  28. 

Present  packet  switches  are  based  on  and  captive  to  a minicomputer 
technology  which  may  be  obsoleting.  Rapid  advances  in  LSI  technology 
and  microprocessor  development  are  producing  major  cost  and  size  re- 
ductions in  logic  hardware  which,  taken  together  with  progress  in 
memory  technology,  provide  an  opportunity  to  study  the  advantages  of 
designing  packet  switches  with  alternative  hardware  configurations  to 
the  minicomputer  approach.  The  possibility  exists  of  exchanging 
hardware  for  software.  That  is  to  say,  with  hardware  costs  suffi- 
ciently reduced,  it  may  become  advantageous  (Ref.  75)  to  assign  the 
more  repetitive  and  most  often  used  functional  tasks  of  the  packet 
switch  to  their  own  special-purpose  (’’hard  wired’’)  switch  components 
or  hardware  modules,  rather  than  utilize  the  present  approach  of  spe- 
cialized software  modules  executed  on  a multiprogrammable  general- 
purpose  CPU  and  memory  architecture. 

Multilevel  security  requirements  and  specialized  subscriber  inter- 
face and  control  will  also  be  factors  influencing  switch  architecture 
and  design  research  and  development.  The  packet- switching  function, 
as  realized  with  computer  technology,  will  be  required  to  satisfy 
multilevel  security  standards  for  switching  data  traffic  with  mixed 
security  levels.  These  standards  should  have  a more  limited  scope 
than  those  required  for  general-purpose  (subscriber)  computers.  The 
hardware  architecture  as  discussed  above  as  well  as  intra-  and  inter- 
switch logical  function  (i.e.,  adaptive  routing)  will  provide  impor- 
tant alternatives  toward  meeting  security  standards  for  data  switches. 

Another  related  area  requiring  investigation  is  the  interrelation- 
ship of  data  switch  design  (including  circuit  and  hybrid  concepts  as 
well  as  packet)  with  regard  to  network  control,  priority  preempts,  and 
growth  in  capacity.  These  are  broad  network  issues  but  do  have  im- 
pact on  specific  architecture  and  design  of  the  switch  and  methods  of 
expansion  in  switching  capacity  on  the  traffic  load  increases  over 
time. 

175 


3.  Circuit  Switching 

The  array  of  conventional  electromechanical  circuit  switches  now 
operating  in  the  telephony  plant  are  inadequate  for  providing  econom- 
ical switched  service  data  communications  between  advanced  types  of 
terminals  and  computers,  especially  for  interactive  and  inquiry /re- 
sponse type  of  traffic.  The  principal  deficiency  is  the  excessive 
amount  of  time  (5-10  sec)  taken  to  set  up  the  call  by  the  several 
switches  traversed  in  the  connection.  Also  of  considerable  concern 
is  the  occasional  (and  at  some  sites)  selection  of  a poor  quality 
circuit  which  produces  too  many  errors  in  the  received  data.  This 
latter  effect  is  of  considerable  concern  to  bulk  data  transmission, 
such  as  file  transfer  and  remote  job  entry,  for  which  circuit  switch- 
ing in  theory  is  economical.  These  deficiencies  in  the  dial-up  net- 
work have  been  the  primary  motivation  for  developing  leased  private 
data  networks  based  on  dedicated  point-to-point*  transmission  cir- 
cuits of  stated  minimum  quality. 

To  date,  advanced  technology  development  in  circuit  switching, 
ESS  #4,  has  been  described  in  Ref.  67.  Since  circuit  switching  is 
(1)  economical  for  bulk  transfer,  (2)  appears  to  be  more  "trans- 
parent” to  the  current  ADP  communications  environment,  (3)  has  a more 
developed  security  doctrine,  and  (4'  has  better  understood  network 
control  features,  it  would  seem  that  there  is  need  for  advanced  de- 
velopment in  circuit  switching  for  data  communications.  An  advanced 
data-optimized  circuit  switch  should  have  at  least  the  following 
features: 

1.  Fast  set-up  and  take-down  time  (<  1 sec) 

2.  Handle  large  volume  of  server  call  requests 

3.  Switch  multiplicity  of  line  speeds 

4.  Introduce  negligible  error  rate. 

Common  Carriers  burdened  with  the  responsibilities  of  (1)  oper- 
ating an  enormous  existing  plant,  (2)  integrating  new  services  with 

* 

No  switching  provided  by  the  Common  Carriers. 
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that  plant  in  a profitable  manner,  and  (3)  maintaining  adequate  serv- 
ice growth  to  the  principal  telephone  customers  have  not  been  as 
responsive  to  the  communication  needs  as  desired  by  the  ADP  community. 
However,  with  the  fast  growth  in  data  communications  and  the  emergence 
of  the  Value  Added  Networks , it  can  be  expected  that  there  has  been 
study  and  development  effort  given  to  data  switches  by  both  Common 
Carriers  and  computer-associated  manufacturers.  With  the  developing 
competition  in  commercial  data  communications , primarily  in  the  civil 
sector,  and  little  or  no  DoD  sponsorship  of  data  switches,  it  is 
reasonable  to  conclude  that  details  of  new  developments  in  data- 
switching  equipment  and  especially  planning  for  its  introduction  to 
service  tend  to  be  tightly  held  by  the  developer  as  a commercial 
trade  secret.  Public  knowledge  would  first  be  revealed  by  either 
patent  disclosure  and/or  filing  with  the  FCC  for  service  introduction. 

Certainly,  the  rapid  advances  in  computer  component  technology 
useful  for  developing  new  packet  switches  could  also  be  applied  to 
developing  radically  new  circuit  switches.  Large  arrays  of  repli- 
cating digital  logic  circuits  could  be  utilized  for  fast  digital 
switching  in  place  of  the  cross-point  components  (e.g.,  ferreeds)  of 
the  conventional  cross-bar  architecture.  In  addition,  multiple  micro- 
processors on  a common  or  paralleled  bus  structure  could  be  utilized 
for  rapid  serving  of  call  set-up  requests.  (In  the  presently  operating 
electronic  switches  a conventional  computer  architecture  is  used  for 
serving  calls  and  cross-bar  switch  control.)  From  a functional  point 
of  view,  a new  data-oriented  fast  circuit  switch  would  differ  from  a 
new  packet  switch  principally  in  the  deletion  of  the  store- and- forward 
feature  and  adaptive  routing. 

4.  Summary 

The  issues  of  subscriber  aggregation  and  network  regionalization 
go  well  beyond  switching  technology.  They  nevertheless  interact  very 
strongly  with  choice  of  switching  technique  and  specific  design  de- 
tail. Economics  of  scale  versus  user-unique  specialized  services 
versus  reliable  availability  versus  system  control,  and  so  on,  play 
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a dominant  role  in  setting  policy  for  the  evolution  of  networks  and 
their  management.  It  would  seem  clear  that  both  packet-  and  circuit- 
switching methods  or  hybrids  will  be  utilized.  The  need  now  is  for 
a rational  method  to  aggregate  user  requirements  to  determine  net- 
work^) topology  and  select  a mix  of  switching  (including  control) 
technique.  From  this  would  follow  specific  switching  functional  ob- 
jectives for  which  R&D  in  switching  technology  could  be  pursued  uti- 
lizing the  rapid  advances  in  LSI  and  memory  technology  as  well  as 
developments  in  computer  architecture  and  structured  programming. 
Perhaps  of  primary  concern  to  DoD  teleprocessing  applications  is 
switch  architecture  and  design  that  will  meet  the  multilevel  security 
needs  imposed  on  a network. 

The  principal  advantage  of  the  packet  technique  resides  in  its 
flexible  dynamic  allocation  of  trunk  and,  with  adaptive  routing,  high 
utilization  of  overall  network  transmission  capacity  on  a nearly  in- 
stantaneous demand  basis.  If  enhanced  survivability  of  communications 
connectivity  is  of  central  importance,  packet  switching  with  adaptive 
routing  provides  a major  advantage.  On  the  other  hand,  for  bulk  data 
transmission  such  as  file  transfer  and  RJE,  circuit  switching  pro- 
vides more  efficient  use  of  the  transmission  plant  areas  that  have 
to  be  addressed--subscriber  interface  and  access  control.  Packet 
switching  tends  to  require  a more  standardized  interface  while  cir- 
cuit switching  allows  much  more  flexibility  to  the  subscriber.  Ad- 
ditionally, network  flow  control  with  priority  preempts  is  not  as 
well  understood  with  packet  switching.  Hybrid  techniques,  which  pro- 
vide a mix  of  packet-  and  circuit- switching  features,  are  also  pos- 
sible and  desirable. 

Network  analysis,  initially,  can  only  be  mathematically  idealized. 
As  systems  are  implemented,  the  analytical  models  will  have  to  be 
further  developed  (specialized)  relative  to  the  details  of  network 
specifics.  The  principal  analytical  tools  used  to  date  are  the  theory 
of  stochastic  flow  on  graphs  (networks)  and  queueing  theory.  Cost  and 
performance  comparisons  between  packet-  and  circuit- switched  networks 


have  many  degrees  of  freedom  involving  parameter  values  which  will 
have  to  be  derived  from  extensive  data  bases.  At  this  early  stage, 
parameter  elements  have  yet  to  be  properly  identified  or  structured 
(i.e.  , interrelated).  Consequently,  the  real  data  bases  necessary  to 
obtain  values  for  the  parameters  are  yet  to  be  generated  nor  is  it 
clear  yet  how  to  generate  them.  The  scope  of  such  comparison  effort 
includes  (1)  complex  paired  user  requirements  matrices  (to  include 
"processed”  requirements  where  "like"  requirements  are  aggregated), 
(2)  tariff  cost  for  transmission  lines  and  local  loops,  (3)  nodal 
(switch  and  access)  performance  and  costs,  (4)  kind  of  network  to- 
pology, and  (5)  routing  strategy,  etc.  Often  overlooked  and  very 
difficult  to  predict  are  software  costs  associated  with  the  system 
concept. 

In  a purely  technical  context  (leaving  aside  issues  of  regula- 
tory constraints,  investment  in  product  lines,  proprietary  rights 
and  the  like) , it  would  appear  wise  to  expect  a mix  of  packet  and 
circuit  switching  for  system  implementation  in  data  networks.  As 
previously  observed , this  strongly  relates  to  the  aggregation  of 
user  requirements  and  service.  The  outstanding  problem  will  be  to 
develop  planning  capability  to  (1)  design  the  initial  aggregate  users 
and  networks  or  subnetworks  for  this  support,  (2)  followed  by  evo- 
lutionary growth,  i.e.,  network  extendability.  A very  important 
issue  is  the  need  to  provide  a framework  for  correlating  the  many 
diverse  R&D  activities  in  teleprocessing  with  regard  to  a network- 
ing strategy.  So  far,  the  cost  for  network  R&D  would  appear  to  be 
relatively  low. 

D.  NETWORK  CONTROL 

Underlying  much  of  the  discussion  in  this  report  has  been  the 
problem  of  system  and  network  control:  control  between  user  com- 
puter and  terminal  equipment,  control  of  user  access  to  network,  and 
control  within  a network.  Inadequate  control  will  produce  at  the 
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very  least  congestion  within  the  network.  Common-user  networks,  if 
they  are  to  operate  at  economical  traffic  loading,  must  have  an  adequate 
control  system.  For  teleprocessing  systems  with  dedicated  communica- 
tion facilities,  the  network  control  is  imbedded  within  overall  system 
control.  To  date,  control  has  been  treated  as  an  add-on  feature  to 
a specified  system  concept.  As  such,  careful  factorization  of  con- 
trol tasks  is  usually  not  essential.  The  overall  control  approach 
derives  from  the  specific  system  needs.  However,  for  common-user 
networks , careful  definition  and  examination  of  the  control  tasks , 
their  functional  implementation,  assignment  of  responsibility,  etc. , 
are  essential.  Control  will  impact  the  balance  between  and  develop- 
ment of  dedicated,  shared,  or  common-user  networks,  and  their  growth 
and  evaluation  as  well  as  strongly  influencing  which  component  tech- 
nologies will  dominate. 

Inadequate  control  can  result  in  several  types  of  very  undesir- 
able effects  on  performances.  Among  these  are: 

• Delay  in  service  or  even  logic  blocking  of  ADP/terminal 
sites  and/or  network  facilities 

• Inadequate  availability  of  transmission  services 

• Intermittent  loss  of  connectivity 

• Inadequate  throughput 

• Unnecessary  increase  in  network  capacity  and/or  ADP 
site  facilities . 

In  addition  to  technical  problems , there  could  develop  management- 
oriented  difficulties  relating  to  areas  of  responsibility,  such  as 
maintenance,  fault  allocation  and  fault  correction,  priorities  of 
network  actions,  and  developments,  etc. 

In  all  of  the  analyses  in  the  references  discussed  in  Section 
V-C,  control  features  are  explicitly  examined  or  implicitly  assumed 
within  the  context  of  the  mathematical  treatment.  Control  factors 
are  involved  with  (1)  regard  to  defining  functions  and  interactions 
between  elements  of  concept,  e.g.,  system  architecture,  (2)  optimi- 
zation of  system  parameters,  and  (3)  choice  of  operating  network 
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access  and  switching  strategies.  Research  in  network  control  to 
date  has  been  pursued  within  the  context  of  a dedicated  system  or 
ARPANET  type  of  common-user  network.  In  either  case,  a specific 
type  of  network  architecture  and  concept  of  operations  are  assumed. 
Consequently,  the  results  tend  to  specialize  according  to  the  type  of 
network  assumed. 

As  seen  in  Section  V-C,  the  theoretical  basis  for  flow  control, 
a major  element  of  network  control,  is  only  in  its  infancy.  Consid- 
ering the  essential  role  of  control,  there  is  an  urgent  need  to  sup- 
port studies  in  network  control.  Several  principal  network  modes 
(shared  facilities,  piggyback,  common  user)  should  be  nominated  for 
study.  Within  each  mode,  selected  examples  of  likely  network  archi- 
tecture and  associated  operational  concept  could  be  studied.  For 
these  sets  of  hypothetical  networks,  control  functions  should  be 
carefully  factored  (i.e.,  subdivided)  and  analyzed,  including  varia- 
tions on  the  factoring.  As  work  progresses,  review  should  be  pointed 
toward  identifying  analytical  techniques,  results,  and  principles  of 
operation  common  to  various  network  types.  Hopefully,  this  would 
provide,  in  a bootstrap  fashion,  characterization  and  relationship 
between  control  and  network  design.  If  successful,  such  results 
would,  in  turn,  provide  needed  guidance  in  formulating  system  simu- 
lation and  experimental  tests . 

E.  MULTILEVEL  SECURITY  FOR  DATA  TRANSMISSION 

This  section  draws  attention  to  and  differentiates  between  the 
security  problems  for  subscriber  host  computers  as  opposed  to  those 
for  switched  data  transmission  networks.  An  excellent  and  detailed 
review  of  this  problem  is  provided  in  Appendix  G of  Ref.  5.  The  in- 
tent is  to  outline  what  are  to  be  the  key  areas.  The  security  problem 
area  is  highlighted  here  because  of  its  critical  importance  to  DoD 
applications. 

The  central  current  fact  is  that  to  date  there  are  no  known 
(i.e.,  proven)  solutions  to  the  multilevel  security  problem  for 
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multiprogrammed  computers,  not  to  speak  of  computer  networks.  Fur- 
thermore, although  there  has  evolved  considerable  doctrine  for  trans- 
mission security  developed  for  voice  and  narrative  record  communica- 
tion services,  there  exists  very  little  experience  upon  which  to  base 
security  requirements  for  interactive  switched  data  communication 
services.  There  will  be  a need  to  develop  new  security  doctrine 
suitable  for  teleprocessing  networks. 

Security  limited  to  the  switched  transmission  facilities  is 
probably  more  easily  achieved  than  that  needed  for  time- shared 
general-purpose  host  computers.  The  principal  technical  unknown  is 
presented  by  the  switching  nodes.  Current  practice  can  secure  the 
internodal  transmission  facilities.  Since  the  nodal-switching  func- 
tions can  be  made  explicit  and  are  limited  (in  contrast  to  general- 
purpose  ADP)  and  since  the  cost  of  switch- component  processor  hard- 
ware should  not  be  large,  it  is  reasonable  to  expect  nodal  switches 
to  be  made  secure.  Data- switching  nodes  with  security  should  be 
realizable  with  small  special-purpose  "computers,"  which,  if  neces- 
sary, can  use  physical  duplication  of  existing  minicomputer  technol- 
ogy. Alternatively,  specialized  new  switch  architecture  based  upon 
microprocessor  technology  could  be  employed.  The  basic  uncertainty 
is  not  yet  having  an  adequate  overall  objective  or  perception  for 
network  security  standards  for  which  to  delineate  specific  switch 
requirements. 

It  is  this  lack  of  an  overall  system  perception  which  is  crucial. 
Although,  in  principle,  the  transmission  portion  of  a data  network 
can  be  made  secure,  it  is  not  at  all  clear  that: 

1.  The  internetting  of  subscriber  ADP  remains  secure 
(the  host  multilevel  security  issue). 

2.  The  transmission  network  will  remain  economically  feasible. 

3.  The  breadth  of  subscriber  interconnectivity  can  be  sus- 
tained (e.g.,  crypto  key  distribution). 

Items  1 and  2 directly  relate  to  determining  overall  system  security 
as  a balance  between  the  transmission  facilities  and  subscriber 
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facilities.  Items  1,  2,  and  3 impact  heavily  on  the  two  major  ad- 
vantages of  a common-user  switched  data  transmission  network,  namely, 
economies  of  scale  in  shared  facilities  and  on-call  interconnectivity 
between  infrequently  linked  subscriber  "pairs." 

The  preceding  paragraphs  emphasize  the  security  issues  limited 
to  data  transmission.  It  clearly  interrelates  with  the  subscriber 
host  computer  security  in  terms  of  doctrine,  responsibility  and  cost. 
Not  immediately  obvious,  however,  is  the  commensurate  time  phasing 
needed  between  transmission  network  security  and  multilevel  host  com- 
puter security.  No  high-confidence  approach  has  yet  been  evolved  for 
this  latter  problem. 


F.  NETWORK  INTERCONNECTION 

A problem  area  that  can  be  expected  to  be  of  impcrtance  in  the 
future  will  develop  from  the  desirability  or  necessity  to  interconnect 
different  networks.  This  issue  has  already  been  raised  by  the  desire 
to  interconnect  or  interface  the  SATIN  IV  network  with  versions  of  a 
projected  AUTODIN  II  network.  It  should  become  of  considerable  im- 
portance to  be  able  to  interconnect  within  the  DoD  certain  networks , 
especially  Type  I with  key  Type  II  networks.  A potential  role  identi- 
fied for  AUTODIN  II  would  be  to  provide  such  an  interconnection  in 
an  on-demand  or  as-needed  basis  (a  network's  network). 

Very  little  is  presently  known  about  the  problems  to  be  encoun- 
tered when  interconnecting  networks.  Clearly,  factors  to  be  considered 
are  the  topological  relationships  of  the  points  of  network  interconnects, 
data  interface  standards  and  protocols , partition  and  interaction  of 
control,  assignment  of  cross-network  responsibilities,  etc.  New  classes 
of  problems  may  be  generated  in  regard  to  multiple  routing,  integrity 
of  cross-network  messages,  and  internetwork  control  stability.  A re- 
cent paper  by  Cerf  and  Kahn  (Ref.  76)  discusses  some  of  these  issues 
as  they  relate  to  interconnecting  ARPANET-type  networks. 

The  interconnection  of  networks  must  clearly  build  on  the  knowl- 
edge and  experience  gained  with  the  use  of  dedicated,  shared,  and 
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common-user  systems.  All  of  the  problem  areas  and  development  needs 
discussed  in  the  previous  sections  for  self-contained  networks,  from 
requirements  through  control,  are  applicable  in  addition  to  new 
classes  of  problems  that  will  be  generated.  In  addition  to  seeking 
convenient  data  interface  standards  and  maintaining  efficient  cross- 
network throughput,  attention  must  also  be  directed  to  at  least  the 
following: 

• Functional  interface  factors,  e.g.,  formats,  protocols, 
speed  of  response 

• Logic  compatibility 

• Message  integrity  and  responsibility 

• Internetwork  control  stability 

• Fault  recovery 

• Cross-network  security. 

A definitive  and  constructive  set  of  technical  standards  for  network 
interconnection  will  be  difficult  to  develop  without  a more  comprehen- 
sive Do D requirements  policy  for  network  data  transfer  and/or  inter- 
operability. 

As  pointed  out,  our  knowledge  of  self-contained  networks,  let 
alone  interconnected  networks,  is  not  adequate.  At  this  early  junc- 
ture, emphasis  can  be  given  to  the  desirability  of  interconnection 
and  study  effort  directed  at  identifying  the  interconnection  problems 
generated  by  their  dependence  on  the  specifics  of  proposed  networks. 

G.  COMPUTER  SCIENCE 

The  previous  areas  of  need  discussed  in  this  section  were 
oriented  toward  supporting  the  development  of  data  communication 
networks.  Certainly,  the  ability  to  utilize  the  teleprocessing 
opportunities  afforded  by  networks  and  then,  in  turn,  derive  addi- 
tional guidelines  and  priorities  for  network  objectives  strongly 
depend  on  continued  or  even  enhanced  R&D  in  computer  science.  Those 
areas  of  computer  science  that  appear  to  be  most  intimately  related 
to  developing  data  networks  include  the  following: 
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• Structure  and  organization  of  Data  Base  Management  systems 
for  multiuser  interactive  applications 


• Interprocess  communication  techniques  and  protocols  to 
support  automatic  dialogue  between  disparate  machines 
and  software 

• Higher  order  computer  language  to  facilitate  all  of  the 
above  items 

• Allocation,  control,  and  evaluation  techniques  for  ADP 
resource  sharing  within  the  context  of  progress  in  the 
above  items. 

It  is  not  the  purpose  of  this  section  to  elaborate  on  the  above.  They 
are  provided  in  order  to  restore  balance  in  perspective  between  R&D 
for  data  communication  and  ADP  utilization.  An  important  managerial 
issue  is  the  need  to  provide  a balanced  and  coordinated  set  of  R&D  ef- 
forts while  generating  much  closer  interaction  and  cross- fertilization 
between  the  computer  science  and  communication  R&D  communities  than 


have  heretofore  existed. 

H.  SUMMARY 

This  section  has  identified  several  teleprocessing  problem  areas 
requiring  further  research  effort.  The  principal  focus  of  the  dis- 
cussion is  directed  toward  subscriber- oriented  teleprocessing  systems. 
That  is  to  say,  teleprocessing  systems,  whether  dedicated  to  a closed 
community  of  users  or  open  to  general  users,  adopt,  as  a fundamental 
design  philosophy,  the  interconnection  of  multiple  users  on  a sub- 
scriber basis. 

The  areas  identified  for  further  effort  are: 

1.  Requirements  formulation,  activity  modeling,  and  system 
evaluation 

2.  Data  interface  standards 

3.  Data  switching  techniques 

4.  Network  control 

5 . Network  interconnection 
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6.  Multilevel  security  for  data  transmission 

7.  Computer  science. 
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These  areas  are  all  highly  interrelated  in  the  design  of  any  specific 
system.  Of  especial  significance  to  DoD  is  the  multilevel  security 
problem  as  it  pertains  to  both  data  transmission  (area  5)  and  to  sub- 
scriber host  computers  (area  7). 

A general  requirements  formulation  process  is  needed  not  only 
to  design  and  evaluate  new  systems  but  is  also  of  importance  to  pro- 
vide upper  management  with  more  uniform  and  useful  reports  of  utili- 
zation and  status  of  systems  to  make  informed  decisions  as  to  system 
upgrade,  cross-connection,  replacement,  etc.  Data  interface  standards 
are  essential  for  achieving  wide  subscriber  interconnection  and  econ- 
omies of  scale  in  ADP  services  as  well  as  achieving  essential  command 
and  control  information  exchange.  A critical  issue  are  those  standards 
which  involve  logic  interactions  (start/stop,  error  recovery,  iden- 
tification) and  a careful  delineation  of  subscriber- to- subscriber  con- 
trol as  opposed  to  subscriber- to- transmission  network  control,  and 
control  within  the  transmission  network.  Previous  efforts  have  at- 
tempted to  standardize  on  data  formats  and  structure.  Poor  data 
standards  lead  to  inefficiencies*;  inadequate  logic  standards  can 
deny  use  altogether.  Data- switching  technology  (packet,  fast  cir- 
cuit, and  hybrid)  will  have  a strong  role  in  regard  to  standards  and, 
perhaps  even  more  importantly  to  DoD,  in  regard  to  multilevel  security. 
New  microprocessor  and  solid-state  memory  technology  allows  for  de- 
veloping data  switches  with  a shift  in  emphasis  from  software  archi- 
tecture to  new  specialized  hardware  and  firmware  configuration.  For 
common-user  networks,  flow  and  access  control  is  an  essential  need 
to  equitably  provide  transmission  capacity  to  the  subscribers.  For 
DoD  application,  the  need  for  control  methods  is  even  more  pressing 
in  order  to  provide  priority  service  to  the  more  critical  military 
data.  There  is  currently  an  inadequate  understanding  of  this  problem 
area.  Control  methods  will  strongly  interrelate  to  data  interface 
K 

The  economic  implications  of  which  can  preclude  usage. 
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standards,  switching  architecture,  and  the  multilevel  security 
mechanization . 

Multilevel  security  is  an  essential  element  for  DoD  teleprocess- 
ing systems.  There  is,  to  date,  no  known  method  to  provide  adequate 
security  to  teleprocessing  systems.  In  subscriber-oriented  systems, 
it  is  important  to  differentiate  between  subscriber  host/computer 
security  and  security  in  the  switched  data  transmission  facilities. 
Since  switching  nodes  utilize  limited  and  specific  ADP  functions, 
which  can  be  hardware  compartmented  and  housed  in  secure  facilities, 
it  is  reasonable  to  expect  that  switched-data  transmission  security 
will  be  more  easily  or  earlier  achieved  than  that  for  host  computers. 

A basic  issue  is  the  perspective  between  transmission  security  as  op- 
posed to  subscriber  security.  It  is  obviously  not  sufficient  to  have 
one  without  the  other  or  to  overinvest  in  achieving  one  at  the  expense 
of  the  other.  Even  more  fundamental  is  the  likelihood  that  the  secu- 
rity problem  will  not  neatly  factor  into  subscriber  and  transmission 
security  areas.  Taken  separately,  security  may  be  achieved  for  trans- 
mission and  host  sites  but  when  connected  in  a network  weaknesses  may 
present  themselves.  Even  though  subscriber  computers  were  to  be  se- 
cured individually,  it  must  be  verified  that  as  a net,  security  is 
not  compromised.  It  seems  certain  that  new  security  doctrine  will 
have  to  be  evolved.  Due  to  the  fundamentally  new  features  (techni- 
cal, operational,  and  organizational)  of  data  internetting,  a proper 
management  forum  and  plan  are  needed  to  initiate  data  security  mea- 
sui’es . 

It  can  be  expected  that  future  teleprocessing  networks  will  de- 
velop a need  to  interconnect  at  least  selectively  (at  gateway  loca- 
tions) or  itinerantly  in  time  or  both  (e.g.,  a network's  network). 

This  is  an  issue  for  the  future  but  one  which  current  system  planning 
should  take  cognizance.  Very  little  is  known  about  this  subject. 

Areas  of  additional  technical  complexity  beyond  those  mentioned  for 
independent  networks  include:  internetwork  functional  interface, 
logic  compatibility,  message  responsibility,  control  stability,  fault 
recovery,  and  security. 
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The  previous  paragraphs  of  this  summary  principally  address  the 
network  transmission  and  interconnection  functions.  Of  perhaps  even 
greater  significance  are  computer- science-oriented  problems,  especially 
as  the  (as  yet  unknown)  fourth- generation  ADP  context  is  manifested. 
Areas  of  computer  science  that  are  of  especial  importance  to  DoD 
include : 


• Multilevel  security  at  and  between  subscriber  facilities 

• Data  base  management  systems  for  multiuser  interactive  access 

• Interprocess  (software)  communications  techniques  between 


disparate  machines  and  facilities. 

If  current  and  future  R&D  activities  are  left  uncoordinated,  any 
trend  toward  proliferation  of  teleprocessing  systems  and  networks  would 
remain  unchecked. 
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VIII.  DOD  DEVELOPMENTAL  SYSTEMS  AND  STANDARDS 
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The  DoD  has  in  development  a number  of  computer-to-computer  com- 
munications systems . While  there  are  differences  in  the  functions 
performed  by  these  systems,  they  have  many  desirable  features  in 
common  including  reliability,  survivability,  security,  and  responsive- 
ness. There  is  a clear  requirement  to  interconnect  these  systems  and 
to  transfer  data  from  system  to  system,  and  many  of  the  interopera- 
bility difficulties  that  arise  are  due  to  the  independent  develop- 
ment of  the  systems.  A basic  question  that  arises  is  whether  indi- 
vidual systems  indeed  have  such  unique  requirements  that  common 
protocols,  procedures,  and  programs  cannot  be  used  in  and  between 
the  various  networks. 

There  is  and  will  continue  to  be  a need  for  high-level  examina- 
tion of  the  systems  under  development,  first  to  ensure  that  intersystem 
standards,  operating  procedures,  etc.  are  properly  established  and, 
second,  that  the  resources  and  technology  which  are  developed  are 
shared  among  the  system  programs.  The  considerations  and  problems 
discussed  in  the  following  sections  concerning  DoD  teleprocessing 
systems  now  in  development  indicate  a need  for  immediate  action  in 
two  areas:  (1)  the  establishment  of  several  DoD  standards  for  proto- 
cols for  teleprocessing  systems,  and  (2)  the  development  of  a set  of 
highly  modular  standard  programs  for  use  throughout  the  DoD.  These 
should  include  service  programs  (e.g.,  data  base  management  systems 
such  as  NIPS,  WWDMS,  and  FMIS)  and  applications  programs  (e.g., 

FORSTAT  AND  JOPS). 

The  establishment  of  DoD  standards  would  have  two  immediately 
ascertainable  salutary  effects.  First,  they  would  facilitate  the 
interoperability  of  such  systems  as  SATIN  IV,  the  AABNCP,  and  the 
WWMCCS  computers  at  the  ANMCC  and  NMCSSC,  and  permit  these  development 
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programs  to  continue  with  less  chance  of  future  complications  or  prob- 
lems. Second,  if  care  is  taken  to  ensure  that  the  standards  developed 
are  generally  compatible  with  what  appear  to  be  the  developing  industry- 
wide standards  [for  instance,  the  ANSI  Advanced  Data  Communication 
Control  Procedure  (ADCCP)  based  on  the  IBM-proposed  Synchronous  Data 
Link  Control  (SDLC)],  then  compatibility  with  commercial  gear,  such  as 
terminals,  would  be  ensured.  In  addition,  it  appears  sensible  for  DoD 
to  work  closely  with  ANSI  to  establish  standards  so  that  DoD-designed 
systems  will  be  immediately  compatible  with  commercially  designed 
systems  which  implement  the  ANSI  standards . 

The  development  and  implementation  of  highly  modular  standard 
service  and  application  programs  are  called  for  by  similar  reasoning. 
Given  that  a user  can  establish  a communication  link  with  a given 
computer,  unless  he  knows  and  understands  the  standards  and  use  of 
service  programs  (such  as  the  data  base  management  system's  query 
language  or  how  to  use  application  programs  such  as  FORSTAT),  he  still 
cannot  effectively  obtain  information  or  interact  with  these  programs . 
Teleprocessing  requires  widespread  data  and  information  standardiza- 
tion for  successful  interchanges  at  all  levels. 

A.  SYSTEM  STANDARDS 

The  DoD  faces  a large  investment  in  software  with  the  multiplicity 
of  different  systems  now  being  developed.  Only  through  industrywide 
standards  can  DoD  economically  ensure  that  major  systems  procured  from 
different  manufacturers  will  be  able  to  communicate  through  common- 
user  or  special  dedicated  communication  systems.  Many  of  the  problems 
that  are  now  appearing  (and  will  increase  in  the  future)  can  be  elim- 
inated or  alleviated  by  proper  action  at  this  time.  Program  delays 
and  additional  costs  that  have  appeared  in  early  phases  of  programs 
now  in  progress  could  increase  if  standards  are  not  developed. 

The  DoD  has  been  a leader  in  developing  standards  and,  in  the 
computer  area  in  particular,  the  DoD  has  been  responsible  for  develop- 
ing standards  that  have  become  widely  used  in  industry.  For  example, 
the  computer  language  COBOL  is  now  the  most  used  language  in  industry 
as  well  as  in  the  DoD,  and  was  developed  with  the  active  participation 
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and  drive  of  the  DoD.  Standards,  such  as  the  Mil  806,  which  became 
the  ANSI  standard  for  graphic  symbols  for  computers , were  developed 
by  the  DoD  adopting  and  improving  an  industry  standard  not  in  wide- 
spread use.  In  this  case,  the  enforcement  of  the  DoD  standard  led  to 
an  almost  universal  industry  adoption.  A similar  situation  exists 
regarding  the  computer  language  FORTRAN,  where  DoD  and  Government 
actions  have  led  to  widespread  use  of  a particular  version  of  an 
already  existing  language. 

In  the  area  of  teleprocessing,  the  DoD  has  already  established  a 
technology  base  that  can  fortunately  be  used  to  develop  standards. 
This  base  includes  the  ARPA  funded  and  directed  ARPANET  program, 
which  is  the  first  large  interactive  teleprocessing  network  that  in- 
cludes diverse  computers  and  terminals.  The  ARPANET  is  an  ongoing 
development  but  already  provides,  in  one  form  or  another,  many  of 
the  features  generally  considered  to  be  desirable  in  teleprocessing 
systems.  The  DoD  also  has  several  teleprocessing  systems  in  various 
stages  of  development  and  a prototype  system,  the  FWIN,  specifically 
designed  as  a support  vehicle  for  further  studies. 


B.  TELEPROCESSING  SYSTEMS  CAPABILITIES 

In  order  to  develop  a background  for  discussing  teleprocessing 
issues,  some  of  the  capabilities  that  can  be  provided  by  teleproc- 
essing systems  are  presented.  Different  systems  have  differing  re- 
quirements, but  the  following  list  encompasses  most  of  the  capabili- 
ties commonly  specified. 

1.  Terminal  Servicing — Interactive  Systems 


An  important  capability  that  can  be  provided  by  an  intercomputer 
communication  system  is  that  of  servicing  terminals  at  local  and  re- 
mote computers.  For  example,  an  analyst  at  a terminal  in  the  Pentagon 
might  wish  to  query  a data  base  located  at  the  MAC  WWMCCS  complex  or 
at  REDCOM  in  order  to  develop  and  cost  contingency  troop  movement 
plans.  This  task  may  well  include  the  running  of  programs  located 
at  the  remote  computer  so  that  the  analyst  may  have  not  only  basic 
raw  data,  but  also  be  able  to  derive  statistics  or  accumulated  data 


using  programs  located  on  the  remote  host.  When  a computer  terminal 
system  is  designed  so  that  the  user  of  the  terminal  is  able  to  query 
the  data  base  or  operate  a program,  examine  the  results  and  then  ask 
for  further  information  from  the  computer  over  a reasonably  short  time 
period,  the  system  is  said  to  be  interactive . 

In  order  for  computer-serviced  interactive  terminal  systems  to  be 
most  effective,  it  is  necessary  to  reduce  the  response  time  so  the 
delays  incurred  by  the  communication  system  are  on  the  order  of  seconds. 

2.  Data  Base  File  Transfers 

A widely  needed  capability  for  DoD  intercomputer  networks  in- 
cludes the  ability  to  transfer  files  from  one  computer  to  another. 

An  example  of  a file  transfer  is  the  periodic  updating  of  the  FORSTAT 
file  in  the  NMCSSC  by  moving  the  updated  file  change  information  from 
the  ANMCC.  In  this  case,  the  ANMCC  computers  perform  the  actual 
FORSTAT  file  updating  and  then  transmit  the  file  update  information, 
which  is  effectively  a file,  to  the  NMCSSC  using  a 50-kilobit  line 
between  the  WWMCCS  computers  at  these  sites. 

The  ability  to  transfer  files  from  computer  to  computer  gives  a 
computer  network  the  ability  to  store  duplicate  files  at  several 
locations,  thus  providing  reliability  and  survivability  in  case  of 
the  loss  of  one  or  more  computers  or  of  the  loss  of  communications 
from  the  decision  maker  to  a computer  which  contains  required  infor- 
mation. Sometimes  cost  savings  can  be  effected  by  sending  file  or 
change  data  from  heavily  loaded  computers  to  computers  that  are  less 
heavily  loaded  where  the  files  may  be  processed.  This  is  called 
load  leveling.  Sometimes  small  computers  can  utilize  larger  computers 
connected  by  communication  links  to  perform  jobs  at  a cost  saving 
since  larger  systems  tend  to  provide  computations  at  a lower  cost. 
Passing  jobs  around  a network  is  called  resource  sharing.  In  any 
case,  file  transfer  is  an  important  function  of  computer  networks, 
particularly  in  command  and  control  systems. 
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3.  Remote  Job  Entr 
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An  example  of  remote  job  entry  is  the  use  of  a card  reader  and 
printer  at  a site  which  is  remote  from  the  computer.  In  this  case, 
the  user's  job  can  be  read  by  the  local  card  reader  and  data  (and 
often  programs)  transferred  to  the  remote  computer  over  the  communi- 
cations system.  The  remote  computer  runs  the  job  in  its  batch- 
processing  mode,  delivering  the  results  to  the  printer  through  the 
communications  network. 

A remote  job  entry  facility  gives  the  user  the  ability  to  use  a 
large  computer  complex  that  is  located  some  distance  from  his  rela- 
tively inexpensive  card  reader  and  printer. 

4.  Teleconferencing 

Teleconferencing  is  the  use  of  a telecommunications  system  to 
interconnect  terminals  which  are  physically  separated  so  that  entries 
at  one  terminal  are  immediately  available  in  printed  form  at  the 
other  terminals.  Computer  networks,  such  as  ARPANET,  provide  a 
teleconferencing  facility  (as  well  as  an  "electronic  mail"  system) 
that  can  eliminate  delays  through  local  communication  centers. 

Using  teleconferencing,  it  would  be  possible  for  a terminal  in  the 
NMCC  to  be  connected  to  terminals  at  the  command  centers  of  MAC  and 
REDCOM.  In  a command  and  control  environment,  this  provides  decision 
makers  and  their  staffs  with  an  important  capability,  rapid  record 
communications,  as  an  easily  provided  offshoot  of  the  intercomputer 
communications  network. 

C.  TELEPROCESSING  SYSTEM  PROTOCOLS 

When  computers,  terminals,  sensor  systems,  remote  job  entry 
devices  (card  readers,  printers,  etc.)  or  other  digital  devices  are 
interconnected,  procedures  must  be  designed  so  the  devices  can 
communicate  effectively.  These  procedures  can  be  quite  simple  or 
very  elaborate,  depending  on  the  complexity  of  the  information 
transfer  required.  A complete  set  of  procedures  for  interdigital- 
device  communication  is  commonly  referred  to  as  a protocol.  When 
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computers  are  interconnected  using  a communications  network,  several 
different  protocols  may  be  required. 

As  an  example,  in  the  ARPANET  system,  the  data  processing  com- 
puters are  called  Hosts,  and  the  communications  network  basically 
consists  of  a set  of  communication  computers  called  imps,  which  are 
interconnected  using  leased  lines.  The  procedure  a computer  follows 
when  sending  a message  to  or  receiving  a message  from  another  computer 
via  the  ARPANET  entails  a Host-IMP  protocol  (this  is  basically  a 
computer-communications  network  protocol).  The  IMP  communication 
computers  then  communicate  using  an  IMP-IMP  protocol.  Host  computers 
also  have  a Host-Host  protocol  to  facilitate  their  information  trans- 
fers. Because  these  protocols  are  distinct,  they  are  said  to  be 
layered. 

Data  to  be  transmitted  in  the  ARPANET  are  broken  into  segments, 
each  less  than  some  maximal  length,  and  each  segment  is  referred  to 
as  a packet.  As  a part  of  the  protocol,  packets  are  generally 
preceded  by  a leader  telling,  for  instance,  where  the  packet  is  to 
be  sent,  how  long  the  packet  or  complete  message  is,  etc.  A trailer 
at  the  end  contains  check  bits  for  error  detection,  some  padding  if 
necessary,  etc. 

The  protocols  in  the  ARPANET  (and  in  most  presently  planned 
systems)  are  implemented  by  means  of  computer  programs.  In  the 
ARPANET,  for  instance,  computer  programs  in  each  IMP  implement  the 
IMP-IMP  protocol  and  the  IMP  part  of  the  Host-IMP  protocol.  Since 
the  programs  in  a general-purpose  computer  can  be  changed,  the 
protocols  can  also  be  changed  in  a given  system,  and  the  ARPANET 
protocols  have  been  periodically  updated.  This  is  not  without  cost, 
of  course,  and  the  costs  of  programming  (or  reprogramming)  protocols 
are  about  the  same  as  other  programming  costs.  It  should  be  noted 
that  while  the  ARPANET  from  a technology  viewpoint  provides  an 
intercommunication  system  design  strategy  that  can  be  used  to  satisfy 
most  basic  system  requirements,  its  protocols  were  a pioneering  effort 
and  much  has  been  learned  from  its  operation.  As  a result,  it  is 


194 


possible  to  improve  and  enlarge  on  these  protocols  and  to  accommodate 
other  DoD  requirements  such  as  network  security. 

When  different  communications  systems  use  different  protocols, 
the  user  of  one  system  cannot  immediately  connect  to  another  system 
without  reprogramming  his  communications  system  protocol.  The 
reprogramming  need  not  be  at  all  levels,  however.  For  example,  two 
computers  using  the  ARPANET  and  having  a usable  Host-Host  protocol 
would  have  to  change  their  Host-IMP  ( computer-to-communications 
systems)  protocol  to  use  the  CYCLADES  network  (in  France)  but  could 
continue  to  use  the  same  Host-Host  protocol  because  of  the  layering. 

A common  set  of  protocols  is  of  primary  imports /ire  in  the  im- 
plementation of  planned  DoD  systems.  Particular  problems  have  arisen 
and  will  continue  to  arise  from  such  systems  as  SATIN  IV,  NEACP,  the 
WWMCCS  computers,  the  IDN  communications  systems  and  others,  each 
have  differing  protocols.  While  a difference  in  protocols  can  essen- 
tially be  accommodated  by  developing  a set  of  computer  programs  that 
will  convert  from  one  protocol  to  another  and  then  by  adding  com- 
puters at  appropriate  points  in  the  network,  this  solution  is  costly 
and  increases  the  risk  of  delays  and  cost  overruns  during  system 
implementation . 

Examples  of  problems  that  can  arise  when  differing  protocols 
exist  in  different  DoD  systems  are  given  in  following  sections.  A 
description  of  several  systems  now  in  development  is  included  to 
clarify  the  problem  areas. 

An  important  element  in  DoD  systems  that  is  not  present  in  most 
conventional  systems  concerns  mobility.  Terminals  may  be  located  on 
aircraft,  ships,  submarines  or  other  mobile  units  and  as  a result  may 
cross  the  boundaries  of  DoD  systems.  (It  is  not  unthinkable,  for 
instance,  that  the  AABNCP  in  its  NEACP  role  might  find  itself  over 
Omaha.)  Moving  from  one  system  to  another  should  not  limit  communi- 
cations systems'  usability.  An  excellent  way  to  provide  for  unex- 
pected transitions  is  to  have  standard  protocols. 
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D.  FWIN— THE  DOD  EXPERIMENTAL  TELEPROCESSING  SYSTEM 

The  plans  for  the  Prototype  WWMCCS  Intercomputer  Network  (FWIN) 
(briefly  discussed  in  Section  III-B)  calls  for  a communications  subnet 
consisting  of  three  communication  computers  (IMPs)  interconnecting  the 
three  WWMCCS  computers  located  at  JTSA,  NMCSSC,  and  CINCLANT  in  Norfolk, 
Virginia  (Fig.  31).  The  IMPs  in  the  PWIN  system  are  connected  by  50- 
kilobit  full-duplex  leased  lines.  The  IMPs  were  delivered  by  Bolt 
Beranek  and  Newman.  Each  IMP  consists  of  a Honeywell  316  computer  plus 
some  additional  interface  circuitry  and  electronics.  An  additional 
Honeywell  316  computer  is  to  be  located  at  JTSA  as  a network  control 
center  to  monitor  and  control  the  communications  subnetwork. 

JTSA  (RESTON)  NMCSSC  (PENTAGON) 


LANTCOM 

(NORFOLK) 

2-11-75-3 

FIGURE  31 . Prototype  WWMCCS  Intercomputer  Network 


The  basic  ideas  and  communication  techniques  used  in  the  PWIN  sys- 
tem are  derived  from  those  developed  for  ARPANET.  In  both  ARPANET  and 
PWIN,  digital  communications  is  provided  by  breaking  the  stream  of  bits 
to  be  transmitted  to  1000-bit  (or  smaller)  packets  for  transmission 
through  the  communications  subnet.  Each  packet  is  prefaced  by  a short 
sequence  of  bits  called  a leader,  vdiich  contains  such  information  as 
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the  destination  of  the  packet,  the  source  of  the  data,  and  some  adminis- 
trative information  used  by  the  communications  subnet.  A set  of  binary 
digits  is  added  at  the  end  of  each  packet  in  order  to  detect  errors  vhen 
they  occur  in  the  communications  subnet.  Erroneous  packets  are  then 
retransmitted. 

The  IMPS  function  in  the  communication  subnet  as  store-and-f orward 
communications  computers.  In  order  to  transmit  data  from  one  host 
computer  to  another,  the  host  computer  generates  packets  from  its  data 
and  delivers  the  individual  packets  to  the  IMP  to  which  it  is  connected. 
Each  packet  is  then  stored  in  the  IMP,  which  determines  which  leased 
line  will  be  used  to  transmit  the  packet.  This  decision  is  made  by 
means  of  a routing  algorithm. 

IMPs  have  the  ability  to  store  a number  of  packets,  queueing  the 
packets  and  then  delivering  them  to  the  selected  communications  lines. 
The  routing  strategy  is  intended  to  minimize  the  terminal  responses 
for  interactive  systems.  In  the  original  ARPANET  and  FWIN  routing 
strategies,  great  emphasis  was  placed  on  servicing  terminals  so  that 
terminal  users  would  have  responses  from  remotely  located  computers 
in  relatively  short  time  (less  than  a second).  Later  versions  of  the 
routing  strategy  have  attempted  to  increase  the  throughput  or  total 
effective  speed  that  can  be  attained  from  host  to  host  when  a large 
volume  of  data  must  be  transmitted  without  any  serious  degradation 
in  the  response  time  for  the  interactive  terminal  user. 

Perhaps  the  outstanding  success  of  the  ARPANET  has  been  in  the 
ability  of  this  network,  which  comprises  a large  number  of  different 
types  of  computers  at  remote  sites,  to  provide  good  service  to  (1) 
the  interactive  terminal  user,  (2)  the  report  or  message  category  of 
user,  and  (3)  the  bulk  data  or  file  transfer  category  of  user.  The 
ARPANET  protocol,  in  particular  the  leader  and  trailer  design,  is  such 
that  relatively  low  overhead,  somewhere  from  13  to  17  percent  in  the 
tests  so  far,  has  been  obtained. 

While  the  basic  protocols  in  ARPANET  and  FWIN  are  the  Host-Host, 
Host-IMP,  and  IMP-IMP  protocols,  there  are  a number  of  other  protocols 
that  have  been  developed  by  ARPA  for  use  in  this  network.  These  include 
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the  protocols  for  remote  job  entry,  file  transfer,  and  teleconferencing. 
Figure  32  provides  a conceptual  view  of  some  of  these  protocols  and  how 
they  have  been  layered.  It  is  important  to  notice  that  communicating 
devices  or  processes  must  use  the  same  protocols  within  a given  computer- 
computer  network  and  to  realize,  also,  that  these  protocols  are  pri- 
marily provided  by  computer  programs  that  implement  the  protocols  in 
the  Host  computers  and  communication  processors. 


2-11-75-4 


FIGURE  32.  Layering  of  Protocols 

E.  THE  ANMCC-NMCSSC  INTERCOMPUTER  LINK 

In  order  to  clarify  some  of  the  issues  that  arise  when  inter- 
computer networks  are  implemented  by  the  DoD,  two  specific  examples 
will  be  given  in  this  and  the  following  section.  The  first  example 
concerns  computer-to-computer  links  between  the  ANMCC  and  the  NMCSSC. 

(Figure  33  shows  the  original  configuration.  The  two  links  shown  be- 
tween the  ANMCC  and  the  NMCSSC  were  furnished  as  part  of  the  Defense 
Communications  Network.  At  that  time,  the  ANMCC  contained  an  IBM 
360/50  and  the  NMCSSC  an  IBM  365/65.  Communications  between  these 
computers  were  provided  by  means  of  two  IBM  communication  processors 
(both  IBM  2701s),  two  Bell  301  data  modems,  and  a 40.8-kbps  leased 
communications  line.  This  is  a widely  used  commercial  configuration: 
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the  IBM  2701  is  a standard  IBM  interface  computing  device  and  the  Bell 
modems  and  leased  lines  are  standard  AT&T  equipment.  The  second  com- 
munications link  shown  is  between  a Honeywell  system’s  700  ren.ote-job- 
entry  terminal  in  the  NMCSSC  connected  through  data  modems  and  a 
2400-bps  line  to  a Honeywell  355/Honeywell  6060  combination  at  the 
ANMCC.  The  355  is  the  standard  Honeywell  interface  computer  that  is 
used  to  connect  terminals  and  remote-job-entry  devices  to  the  Honey- 
well 6000  series  computers,  which  have  been  procured  for  the  WWMCCS. 
Both  of  these  data  links  are,  therefore,  standard  commercial  configura- 
tions. 
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FIGURE  33.  ANMCC  to  NMCSSC  Intercomputer  Link 

An  example  of  the  use  of  the  IBM  360-to-360  link  in  daily  opera- 
tion and  one  of  the  primary  reasons  for  the  40,8-kilobit  line  (as  op- 
posed to  a more  conventional  slower  line)  concerns  the  running  of  the 
F0RSTAT  update  programs.  The  ANMCC  and  the  NMCSSC  contain  copies  of 
the  FORSTAT  programs;  however,  on  normal  workdays  the  NMCSSC  computers 
are  more  heavily  loaded  than  those  at  the  ANMCC  and  so  the  normal 
FORSTAT  updates  are  performed  on  the  ANMCC  computer  and  the  processed 
file  changes  are  transferred  to  the  IBM  computer  in  the  NMCSSC  using 
the  40.8-kilobit  line.  This  transfer  of  data,  because  of  the  large 
volume  of  data,  requires  nearly  two  hours. 


Because  of  the  presence  of  the  WWMCCS  computers  in  the  ANMCC  and 
NMCSSC,  it  was  decided  to  remove  the  IBM  machines  from  these  locations 
and  transfer  their  functions  to  the  Honeywell  computers.  To  this  end, 
the  FORSTAT  programs  were  rewritten  in  COBOL  so  they  could  be  run  on 
the  Honeywell  computers.  Also,  it  was  necessary  to  replace  the  IBM 
computer-to-computer  link  with  a Honeywell  WWMCCS  computer -to -computer 
link.  Original  plans  called  for  the  configuration  shown  in  Fig.  34. 
The  figure  shows  the  arrangement  for  remote  job  entry  and  terminal 
connections  from  the  NMCSSC  to  the  ANMCC  using  data  modems  and  an 
HIS  355.  (These  again  are  standard  commercial  configurations  and  do 
not  involve  computer-to-computer  data  transfer  or  communication. ) 


FIGURE  34.  Planned  ANMCC-to- NMCSSC  Intercomputer  Link 

The  computer-to-computer  links  involve  two  interface  communi- 
cations computers  for  each  6000  series  computer  because  Honeywell’s 
operating  system  and  network  software  require  either  the  use  of  an 
HIS  355  or  very  considerable  reprogramming.  The  Honeywell  HIS  716, 
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which  is  a Honeywell  minicomputer,  then  has  to  be  used  to  perform  the 
computer  network  functions.  The  programs  for  this  particular  computer 
are  to  be  derived  from  the  ARPANET  programs  which  are  used  in  FWIN; 
thus  the  protocols  in  this  particular  system  will  be  essentially  ARPA 
protocols.  As  a result,  it  is  doubtful  if  the  throughput  will  be  adequate 
for  FORSTAT  transfer  at  present  rates.  Further,  because  of  delays  in 
the  delivery  of  the  software  for  these  particular  computers , an  interim 
system  consisting  of  a direct  link  between  the  two  Honeywell  355s  in 
the  system  has  been  scheduled.  In  order  to  effect  this  particular 
connection,  Honeywell  was  given  a contract  to  modify  the  existing 
Honeywell  355  software  to  make  computer-to-computer  transfer  of  data 
possible,  using  only  the  355s.  This  interim  system,  however,  is 
supposed  to  be  replaced  as  soon  as  the  necessary  software  for  the 
Honeywell  716s  is  completed.  From  a protocol  and  network  viewpoint, 
this  link  would  then  function  as  a segment  of  the  FWIN  network.  It 
should  be  noted,  however,  that  this  is  not  a part  of  the  FWIN  con- 
figuration. Further,  because  of  the  low  file  transfer  rate  in  ARPANET 
and  FWIN  (which  is  primarily  due  to  the  RFNM  and  message  assembly  pro- 
cedure in  the  protocols),  the  planned  lines  will  probably  not  be  able 
to  carry  the  present  40-kbit  file  transfer  load  (10  to  15k  are  ARPANET 
rates).  Nevertheless,  we  will  use  this  planned  configuration  in  our 
description. 

F.  THE  AABNCP- SATIN  IV/ANMCC  INTERCOMPUTER  LINK 

An  excellent  example  of  the  problems  that  can  be  caused  by  dif- 
ferent protocols  arises  in  the  use  of  the  Advanced  Airborne  Command 
Post  in  its  two  roles:  one  as  the  NEACP,  and  the  other  in  its  function 
for  SAC.  The- seven  AABNCP  aircraft  are  to  have  standard  data  proc- 
essing and  communications  equipment.  In  its  NEACP  role,  the  ADP 
requirements  include  obtaining  data  for  attack  assessment,  force 
monitoring,  and  SIOP  following/execution.  The  data  required  are  to 
be  obtained  largely  from  ground-based  WWMCCS  computers,  and  the  NEACP 
is  to  interface  directly  with  the  Honeywell  computers  in  the  ANMCC . 

Since  the  AABNCP  also  functions  in  a SAC  role,  the  interface  was 
originally  specified  to  use  the  SATIN  IV  protocol.  There  has  been 
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considerable  opposition  to  this,  however,  because  the  original 
SATIN  IV  protocols  used  long  leaders  and  headers,  and  the  NEACP  re- 
quirements call  for  an  interactive  system  response  time  that  would  be 
hampered  by  the  complexity  of  the  SATIN  IV  protocols.  The  ANMCC 
Honeywell  computers  also  currently  use  a Honeywell  protocol,  and  will 
have  a common  WWMCCS  protocol  in  the  near  future  and  a FWIN/ARPANET 
programmed  protocol  for  the  ANMCC-NMCSSC  link.  Inclusion  of  the 
SATIN  IV  protocol  would  require  preparing  still  another  program  for 
that  protocol.  Further,  using  the  SATIN  IV  protocol,  the  NEACP 
could  only  communicate  directly  with  the  ANMCC  computers  and  ANMCC 
computers  would  have  to  be  used  to  obtain  data  from  other  WWMCCS 
computers.  The  NEACP  terminal  could  not  enter  the  WWMCCS  inter- 
computer network  directly  because  of  the  protocol  differences,  de- 
spite the  fact  that  the  existing  link  from  the  ANMCC  to  the  NMCSSC 
uses  communications  computers  identical  to  the  interface  computer 
used  for  the  NEACP  to  ANMCC  link. 

One  of  the  proposals  that  has  been  made  to  alleviate  this  prob- 
lem is  to  consider  the  NEACP  as  a terminal  to  the  WWMCCS  computer  at 
the  ANMCC,  and  to  use  existing  Honeywell  programs  and  protocols 
suitably  modified.  This  plan  has  been  considered  on  both  a long- 
and  short-term  basis.  The  problem  that  arises  is  that  the  NEACP 
would  not  have  the  proper  WWMCCS  protocol,  and  that  Honeywell's 
existing  systems  have  no  provision  for  precedence  and,  more  impor- 
tant, little  provision  for  security. 

To  clarify  this  proposal  and  show  the  sort  of  complication  that 
arises  from  mixed  protocols,  Fig.  35  shows  the  proposed  arrangement 
in  block  diagram  form.  In  Honeywell's  terminology,  each  HIS  355 
functions  as  a Front-end  Network  Processor  (FNP)  and  each  HIS  716 
(700  series)  machine  functions  as  a Remote  Network  Processor  (RNP) . 

The  proposal  suggests  the  HIS  355  programs  can  be  used  in  their 
present  form  and  that  the  AABNCP  CPE  be  programmed  to  use  the  Honey- 
well protocols  so  that  the  AABNCP  CPE  appears  as  a terminal  to  the 
HIS  716  in  Honeywell's  standard  716-355-6000  series  configuration. 

An  HIS  716  would  be  connected  (on  the  ground)  to  an  HIS  355  that 
is  connected  to  the  WWMCCS  computer  at  the  ANMCC.  This  computer  would 
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interface  with  the  AABNCP  as  shown  in  Fig.  35.  The  HIS  716  is  re- 
quired at  this  point  because  it  will  contain  the  principal  data  base 
interrogated  by  the  AABNCP.  A preformatted  query  language  would  be 
used  so  that  the  AABNCP  (NEACP)  would  address  most  of  its  queries  to 
the  data  base  in  this  computer.  This  data  base  would  be  updated  from 
the  WWMCCS  computer  in  the  ANMCC. 
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FIGURE  35.  Flow  of  Protocols  in  Proposed  Systems 


In  order  for  the  AABNCP  to  have  the  ability  to  use  the  WWMCCS 
computer  directly  as  well  as  the  data  base  in  the  HIS  716,  programs 
would  be  written  so  that  this  HIS  716  could  interface  the  AABNCP  and 
the  355-WWMCCS  computer  configuration  with  ANMCC.  Thus,  the  protocol 
in  this  HIS  716  will  cause  the  computer  to  "look  like"  an  FNP  to  the 
AABNCP  and  an  RNP  to  the  HIS  355  connected  to  the  IMMCCS  computer. 

Now,  let  us  consider  the  sequence  if  a terminal  on  the  AABNCP 
wishes  to  send  a message  to  a terminal  in  the  NMCSSC.  (The  reverse 
sequence  would  be  required  to  transmit  from  the  NMCSSC  to  the  AABNCP. ) 
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First,  the  AABNCP  terminal's  output  is  sent  by  the  airborne  com- 
munications processing  element  (CPE),  in  the  Honeywell  RNP  protocol, 
to  the  ground-entry  point  and  is  relayed  on  AUTOVON  lines  to  the  HIS 
716  in  the  ANMCC.  The  HIS  716  now  examines  the  received  message, 
determines  it  must  go  to  the  ANMCC -WWMCCS  computer,  and  converts  it 
into  the  RNP-FNP  protocol.  The  HIS  355  then  gives  the  message  to  the 
WWMCCS  computer  using  its  protocol.  Since  the  ANMCC-NMCSSC  link  uses 
FWIN  protocols , the  message  is  then  converted  by  the  ANMCC-WWMCCS 
computer  into  that  system’s  (Host-IMP)  protocol  and  the  HIS  355-716- 
50-kbit-line-716-355  series  in  its  FWIN,  IMP-IMP,  IMP-Host  protocol 
sequence  is  used  to  send  the  message  to  the  NMCSSC.  The  NMCSSC  com- 
puter must  now  examine  the  message,  determine  if  it  is  for  a terminal 
at  the  NMCSSC,  and  then  convert  to  the  Honeywell  FNP  protocol. 

What  the  above  illustrates  is  the  type  of  complication  arising 
from  mixed  protocols  and  it  is  interesting  to  calculate  the  number  of 
protocol  changes  in  the  above  simple  communications  situation  which  are 
realistic  and  could  be  expected  to  occur.  It  was  the  seriousness  of 
problems  of  this  kind  that  led  to  attempts  to  reconcile  SATIN  IV  and 
other  protocols  as  well  as  to  develop  various  work-around  strategies. 

At  present,  on-going  programs  must  deal  continually  with  the  variety 
of  protocols  now  being  used  or  considered,  and  delays  and  higher  costs 
are  already  beginning  to  appear  because  of  the  lack  of  resolution  of 
some  of  the  protocol  problems.  Immediate  action  needs  to  be  taken  to 
alleviate  intersystem  protocol  problems  in  the  future  among  systems 
which  must  regularly  interface. 

The  need  for  compatibility  of  the  SATIN  IV  protocols  points  out 
the  advantages  of  a common  protocol  for  some  DoD  users.  If  the  AABNCP 
must  interface  with  the  WWMCCS  computers  in  its  NEACP  function  and 
also  with  SATIN  IV  in  its  SAC  Airborne  Command  Post  function  and  if 
SATIN  IV  and  the  WWMCCS  use  different  protocols,  then  the  mismatch  of 
protocols  would  entail  extra  programming  for  computers  which  have  been 
planned — at  best — or  both  additional  computers  and  extra  programming 


While  all  of  the  above  interface -protocol  problems  can  be  solved 
singly  as  they  arise,  there  is  always  a cost  involved.  Also,  it  is 
difficult  to  predict  every  case  that  might  arise  in  the  future,  and 
the  adoption  of  common  protocols  now  will  give  future  flexibility. 

The  existence  of  DoD  standards  in  the  computer  communications  areas 
would  alleviate  or  eliminate  many  of  the  above  problems  in  systems 
design.  The  DoD  now  has  sufficient  experience  and  an  adequate  tech- 
nology base  to  begin  protocol  standard  design,  and  immediate  steps 
need  to  be  taken. 

G.  DEVELOPMENT  OF  STANDARD  SOFTWARE  PACKAGES 

The  costs  of  computer  software  have  been  sufficiently  high,  and 
the  delays  in  software  production  sufficiently  long  in  both  industry 
and  DoD  that  we  frequently  hear  the  phrase  "the  software  problem." 

There  are,  in  fact,  a number  of  software  problems  (or  at  least  a num- 
ber of  reasons  for  the  software  problem).  One  effective  measure  in 
alleviating  this  problem  lies  in  identifying  system  programs  and  appli- 
cations programs  that  can  be  used  in  a number  of  different  systems  and 
to  develop  these  programs  only  once. 

When  various  users  or  system  developers  are  presented  with  the 
idea  of  sharing  a commonly  produced  program  or  set  of  programs , a 
frequently  heard  response  is  that  the  program(s)  will  not  be  "custom 
made"  or  tailored  to  the  specific  requirements  of  a given  system. 
Fortunately,  good  software  development  concerns  can  now  provide  pro- 
grams that  are  highly  modular  and  in  many  cases  can  custom-fit  a pack- 
age of  the  modules  to  particular  systems.  There  are  already  a number 
of  instances  where  large  modular  programs  have  been  developed  and 
widely  used.  In  some  cases,  programs  adapted  to  the  demands  of  a 
given  system  can  dynamically  adjust  their  operation  to  other  system 
requirements.  In  other  cases,  sets  of  modules  are  compiled  together 
to  fit  the  needs  of  a particular  system.  (This  is  often  the  case  with 
commercial  operating  systems  where  the  system  operator  can  "custom 
make"  his  operating  system  to  his  needs  and  feeling  for  system 
economics . ) 
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For  teleprocessing  systems,  the  need  for  standard  programs,  which 
exist  and  are  operated  at  various  sites,  becomes  even  more  important. 
The  user  of  a teleprocessing  system  does  not  need  the  extra  complica- 
tion of  having  to  know  how  to  operate  different  programs  that  exist 
in  various  places  in  order  to  obtain  the  data  he  desires.  The  system 
user  should  not  have  to  be  multilingual  to  interrogate  similar  files 
in  different  locations.  Further,  if  programs  are  to  interact  or  to 
access  data  at  different  locations,  extensive  translators  or  reformat- 
ting programs  should  not  be  required.  For  economy  of  operation  and 
to  minimize  development  risk,  applications  and  systems  programs  should 
be  jointly  developed  whenever  possible. 

The  administration  of  the  development  of  standard  system  program 
packages  involves  finding  the  areas  where  such  programs  are  needed, 
and  then  seeing  that  the  programs  produced  meet  all  the  systems  re- 
quirements. 

The  arguments  against  standard  software  packages  are  pretty  much 
the  same  as  the  original  arguments  against  standard  versions  of  such 
languages  as  FORTRAN  or  COBOL  which  are  again  not  specifically  made 
for  any  particular  application.  In  the  long  run,  however,  these 
standards  have  proven  cost-effective  and  similar  gains  should  result 
from  developing  standard  software  packages. 

1.  Data  Base  Management  Systems 

As  an  example  of  an  area  where  standard  software  packages  and 
procedures  can  yield  a large  savings  and  also  greatly  facilitate  tele- 
processing system  development,  we  now  examine  Data  Base  Management 
systems . 

A major  part  of  the  data  processing  in  the  DoD  involves  large 
files  of  data.  Common  operations  involve  (1)  searching  these  files 
for  particular  items  or  classes  of  items,  (2)  updating  the  files,  and 
(3)  deriving  statistical  data  from  computer-directed  searches  of  the 
files.  When  a set  of  files  is  organized  and  operated  together,  it  is 
(collectively)  referred  to  as  a database. 
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In  order  to  efficiently  maintain  and  operate  large  data  bases, 
programs  have  been  developed  called  Data  Base  Management  Systems  (DBMSs) 
These  programs  are  in  wide  commercial  use  and  most  major  computer  manu- 
facturers have  Data  Base  Management  systems  available.  The  market  for 
such  systems  is  sufficiently  large  that  a number  of  commercial  soft- 
ware firms  also  provide  such  systems  on  either  lease  or  purchase 
arrangements . 

Data  Base  Management  systems  have  been  used  by  the  DoD  in  the 
past  and  several  such  systems  now  exist  or  are  in  development.  These 
include  NIPS,  the  DBMS  originally  used  in  FORSTAT;  WWDMS,  the  Honeywell 
WWMCCS  system;  and  FMIS,  a SAC  system. 

Different  Data  Base  Management  systems  have  different  features 
and  characteristics.  Basically,  a Data  Base  Management  system  pro- 
vides users  (1)  a language  to  describe  the  data  in  the  files  and  to 
name  the  files  and  data  bases;  (2)  the  ability  to  originate  and  to 
maintain  or  update  the  files  either  on  line  through  terminals , or 
by  using  cards  or  other  input  media;  (3)  a language  and  facility  for 
data  retrieval,  including  the  ability  to  describe  collections  of  data 
using  logical  operators  (list  all  ships  in  the  destroyer  class  and 
with  age  greater  than  20  years);  and  (4)  some  report-generation  fea- 
tures are  often  included  to  facilitate  the  preparation  and  formatting 
of  reports  generated  from  data  in  the  data  base. 

Some  Data  Base  Management  systems  allow  users  to  program  using 
COBOL  or  some  other  standard  language  and  use  the  DBM  to  handle  all 
the  data  base  handling  details;  other  DBMS  provide  all  the  programming 
and  other  languages  internally  (NIPS,  for  instance,  is  in  this  category) 

As  can  be  surmised,  in  a teleprocessing  environment  there  is  a 
considerable  advantage  in  having  similar  data  structured  in  the  same 
way  at  various  locations  in  the  network.  This  permits  more  efficient 
system  operation,  reducing  the  need  for  expensive  translator  or  re- 
formatting programs,  and  also  facilitates  in  the  moving  of  personnel 
from  site  to  site  without  extensive  retraining,  etc.  Similarly, 
having  a standard  query  language  reduces  the  need  for  "multi-lingual” 
specialists  in  obtaining  data  retrievals.  In  some  operational  situa- 
tions this  would  be  very  important. 
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Standard  Applications  Program s 


A good  example  of  a large  program  developed  by  the  DoD  is  that 
used  by  the  Force  Status  and  Identity  Information  Processing  System 
(FORSTAT).  This  system  provides  current  information  on  the  status 
and  location  of  military  resources  as  required  by  the  JCS  and  Na- 
tional Command  Authorities.  Management  of  the  FORSTAT  is  provided 
by  the  Status  of  Forces  Branch  of  the  Operations  Directorate. 

The  FORSTAT  reporting  structure  was  developed  by  the  Data  Pro- 
cessing Division  of  the  Operations  Directorate  of  the  Joint  Chiefs 
of  Staff,  and  is  a part  of  the  Joint  Reporting  Structure.  The 
FORSTAT  Data  Processing  System  was  developed  by  the  National  Mili- 
tary Command  System  Support  Center  which  also  maintains  and  operates 
the  system.  Two  characteristics  of  the  FORSTAT  programs  are  of 
particular  interest:  (1)  identical  FORSTAT  programs  are  located  and 
operated  at  several  locations  in  the  Worldwide  Military  Command  and 
Control  System,  and  (2)  the  original  FORSTAT  programs  were  developed 
using  a Data  Base  Management  system  called  NIPS. 

The  FORSTAT  programs  are  operated  in  four  different  modes,  each 
corresponding  to  a different  operational  level  (JCS,  Service,  CINC, 
and  Major  Command).  While  different  capabilities  are  available  at 
each  operational  level,  the  data  base  maintenance  is  identical  in 
all  four  modes.  At  present  the  operational  modes  and  users  are: 


1. 

JCS  Mode 

JCS 

ANMCC 

2. 

Service  Mode 

Air  Force 
Marine  Corps 

3. 

CINC  Mode 

CINCEUR 

CINCPAC 

4. 

Major  Command  Mode 

AREUR 

USA  Ft 

PACAF 

ARPAC 

There  are  several  advantages  in  having  the  same  programs  at  a 
number  of  installations.  Some  of  the  more  obvious  advantages  accrue 
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from  the  fact  that  system  c_  urators  can  be  readily  transferred  between 
these  locations  with  little  additional  training  required;  the  original 
programs  were  only  prepared  once,  not  at  each  site;  training  and  docu- 
mentation need  only  be  prepared  once,  program  corrections  and  updates 
are  facilitated,  etc. 

In  a teleprocessing  environment  where  updating  of  files  takes 
place  using  communication  links  between  computers,  there  are  several 
additional  advantages  to  having  common  programs  at  the  various  sites. 
Since  the  data  are  maintained  in  identical  formats,  file  transfers 
and  updates  are  greatly  facilitated  and  can  be  made  on-line  without 
format  conversions.  Another  not  so  obvious  advantage  lies  in  the 
fact  that  a terminal  user  can  interrogate  files  at  various  locations 
using  the  same  query  language.  If  the  programs  were  not  standard  at 
the  sites,  either  a user  would  have  to  learn  several  languages  in 
order  to  use  the  different  systems,  or  language  translators  would 
have  to  be  developed  to  translate  the  users'  requests  at  each  dif- 
ferent site.  (This  problem  could  be  alleviated  by  use  of  a common 
Data  Base  Management  system  at  the  different  sites.) 

The  original  FORSTAT  programs  were  developed  using  a DoD-spon- 
sored  Data  Base  Management  system  which  has  seen  considerable  usage 
called  the  National  Military  Command  System  Information  Processing 
System  360  Formated  File  System  (NIPS).  This  system  was  developed 
by  the  National  Military  Command  System  Support  Center  for  the  IBM 
360/370  series  of  computers  (IBM  provided  the  programming  support). 

The  NIPS  is  used  as  a DBM  in  FORSTAT  and  has  been  used  in  several 
other  applications.  The  processing  functions  provided  by  NIPS  are 
standard,  including:  (1)  file  definition,  generation,  maintenance, 
and  revision;  (2)  data  retrieval  including  a query  language  with 
logic  capabilities;  (3)  terminal  processing  (display  features  are 
also  included);  (4)  report  generation  with  some  formatting  features; 
and  (5)  a set  of  utility  programs  including  provision  to  use  COBOL, 
FORTRAN,  and  other  languages  in  a subprogram  call  mode  of  operation. 

NIPS  can  operate  under  all  of  IBM's  most  used  operating  systems, 
and  the  terminal  servicing  features  will  accommodate  IBM  and  other 
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manufacturers’  compatible  terminals.  NIPS  is  a self-contained  package 
that  provides  its  own  programming  language  and  its  own  query  language, 
as  well  as  the  necessary  language  for  data  definition.  In  this,  NIPS 
differs  from  many  commercial  DBMS  which  use  COBOL  or  PL-1  as  their 
programming  language. 

Because  of  the  decision  to  base  the  WWMCCS  computer  system  around 
the  Honeywell  6000  series,  the  FORSTAT  programs  were  redone  for  the 
Honeywell  machines  (by  IBM  programmers),  and  the  converted  programs 
are  now  operational.  Since  no  adequate  DBM  was  available  on  the 
Honeywell  machines,  the  programs  were  rewritten  in  COBOL  without 
support  of  a DBM. 

Another  Data  Base  Management  system  in  the  DoD  used  on  the 
WWMCCS  computers  is  the  Force  Management  Information  System  (FMIS) 
developed  and  operated  by  the  Directorate  of  Operation  Support, 
Assistant  Chief  of  Staff  for  Data  Systems,  Headquarters  Strategic 
Air  Command.  The  FMIS  was  developed  for  the  Honeywell  6080.  The 
FMIS  is  an  updated  and  improved  version  of  an  earlier  DBM,  the 
Time-shared  Data  Management  System  ( TDMS ) , a Government-owned  set 
of  programs  coded  in  JOVIAL.  This  system  provides  standard  functions 
with  some  emphasis  on  fast  file  updating  and  formatting  for  visual 
displays . 

H.  SUMMARY 


The  design  and  construction  of  teleprocessing  systems  that  are 
cost-effective  involve  standardization  of  protocols  and  programs  wher- 
ever possible.  The  standardization  problems  are  more  pronounced  and 
the  lack  of  standards  incurs  greater  costs  in  DoD  systems  because 
some  teleprocessing  systems  are  operated  by  several  different  user 
organizations,  and  there  is  often  a requirement  to  interconnect  these 
different  systems. 

Problems  ensuing  from  different  protocols  are  already  surfacing  and 
are  causing  delays  and  cost  increases  at  an  early  stage  in  the  devel- 
opment of  new  systems.  This  amply  demonstrates  the  even  larger  costs, 
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delays,  and  system  inefficiencies  that  will  arise  if  steps  are  not 
taken  to  formulate  and  sponsor  standard  protocols  for  use  wherever 
possible  throughout  DoD  systems.  The  recent  efforts  in  this  di- 
rection must  be  accelerated  wherever  possible.  Further,  while  DoD 
should  cooperate  with  and  encourage  commercial  standards  groups 
whenever  possible,  because  of  the  urgency  of  the  present  situation, 
interim  DoD  standards  should  be  independently  established  as  soon  as 
possible. 

Similarly,  within  systems  there  is  a need  to  prepare  and  adapt, 
on  a systemwide  basis,  standard  program  modules  (such  as  Data  Base 
Management  systems)  wherever  possible.  The  use  of  these  modules  on 
a systemwide  basis  will  reduce  system  costs  and  enable  system  users 
to  interact  in  an  effective  manner.  Work  in  this  area  should  be 
supported  to  better  determine  desirable  characteristics  for  these 
programs  and  to  provide  a basis  for  determination  of  program  modules 
which  can  be  standardized. 
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APPENDIX  A— TASK  ORDER 


ASSISTANT  SECRETARY  OF  DEFENSE 

WASHINGTON.  D.  C.  20301 


TELECOMMUNICATIONS 


1 I OCT  1973 


ASSIGNMENT  FOR  WORK  TO  BE  PERFORMED 


INSTITUTE  FOR  DEFENSE  ANALYSES 


You  are  hereby  requested  to  undertake  the  following  task: 

1.  TITLE:  Teleprocessing 

2.  TECHNICAL  SCOPE: 


Teleprocessing  is  the  interdependence  of  communications  and  data 
processing  as  a system.  The  objective  of  this  task  is  to  develop  a 
basis  for  evaluating  the  improvements  that  could  result  from  managing 
at  the  teleprocessing  (system)  level  rather  than  at  the  computer  and 
communications  (subsystem)  level.  Factors  to  be  considered  include: 
remote  versus  in-house  processing;  raw  data  versus  preprocessed  data 
versus  compacted  data  transmission;  functional  versus  circuit  switching. 
Guidance  for  the  management,  development,  modification  and  maintenance 
of  teleprocessing  system  to  achieve  potential  improvements  will  be 
developed.  This  will  include  consideration  of  the  following  areas: 

(a)  What  information  should  be  transferred  and  the  extent  of 
resource  sharing  in  a computer  network.  Advantages  or  problems  of 
information  transfer  between  computers  during  peacetime  periods  and 
during  an  emergency  situation. 

(b)  Netting  and  switching  including  interfacing,  protocol  and 
message  formating  for  computer-to-computer  or  terminal- to- computer 
communications. 

(c)  Security  procedures  for  computer-to-computer  communications. 

(d)  Techniques  to  achieve  "graceful  degradation"  of  the  system 
if  computers  become  inoperative  and  for  structuring  the  system  so  that 
relevant  data  are  still  available  to  system  operators  if  either  com- 
munications links  or  computers  become  inoperative. 


(e)  Protection  of  programs  and  data  bases  in  a given  computer  in 
the  system  against  external  interference. 

(f)  Cost  of  software  necessary  to  successfully  implement  a network 
of  computers  in  a command  and  control  system.  Means  for  achieving  soft- 
ware compatibility  within  the  system  and  the  effects  of  establishing  a 
computer  network  on  existing  software,  including  the  effects  of  new 
computer  purchases  for  the  system. 

3*  SCHEDULE:  This  task  shall  commence  July  2,  1973  and  be  completed 
by  June  30,  1974. 

4.  TECHNICAL  COGNIZANCE:  Deputy  Assistant  Secretary.  (Systems) , ASD(T). 

5 • SCALE  OF  EFFORT:  Two  man-years  of  effort,  including  consultants  as 
required  by  IDA,  is  authorized  for  this  task.  Changes  in  the  scale  of 
effort  will  not  be  made  without  the  consent  of  ASD(T). 

6.  REPORT  DISTRIBUTION  AND  CONTROL:  The  Deputy  Assistant  Secretary 
(Systems),  ASD(T),  will  determine  the  number  of  copies  of  reports  and 
their  distribution.  A "need-to-know"  is  hereby  established  in  connec- 
tion with  this  task  and  access  to  classified  documents  and  publications, 
security  clearances  and  the  like,  necessary  to  complete  the  task,  will 
be  obtained  through  the  ASD(t). 


i 


D.  L.  Solomon 
Acting  Assistant  Secretary 


ACCEPTED: 


Alexander  H'- f'lax 
President,  IDA 


DATE:  29  October  1973 


APPENDIX  B 

AUTOMATIC  DATA  PROCESSING  EQUIPMENT  TECHNOLOGY  FORECAST 

INTRODUCTION 

Because  we  are  planning  a system  for  implementation  in  the  late  1970s  and 
early  1980s,  we  need  to  understand  the  costs  and  capabilities  of  the  data  processing 
and  communications  systems  components  that  will  be  available  at  that  time. 
Predictions  of  ADPF.  and  communications  price  and  performance  characteristics  were 
developed  by  Arthur  D.  Little,  Inc.  under  contract.  Their  report,  a major  source  of 
forecast  information,  is  included  as  Annex  A to  Appendix  VI  of  this  report.  Other 
research  on  critical  aspects  of  technology  was  conducted  by  Air  Force  and  MITRE 
personnel. 

The  major  findings  of  these  technology  forecasts  provided  the  basis  for 
developing  system  configurations.  In  addition,  a contract  was  let  to  Boeing  Computer 
Services  to  study  the  problems  and  impact  of  transitioning  from  dispersed,  autono- 
mous computer  operations  to  an  integrated  operation  with  computers  connected  by  a 
telecommunications  network.  Another  contract  went  to  TRW  to  estimate  the  impact 
of  new  software  engineering  approaches  on  software  development  and  configuration 
management. 

AUTOMATIC  DATA  PROCESSING  EQUIPMENT 

In  developing  the  alternative  configurations  needed  for  SADPR-85,  the  Study 
Team  found  it  useful  to  assemble  processing  systems  from  basic  system  components  — 
computers  (including  main  memory),  auxiliary  storage,  and  input/output  terminals. 
The  Arthur  D.  Little,  Inc.  (ADL)  technical  forecasts  were  merged  into  descriptions  of 
these  system  components. 

Processors 

Large  Scale  Integration  (LSI)  processes  dominate  the  manufacturing  plans  of 
ADPE  vendors.  Applied  to  mass-production  items,  such  as  pocket  calculators,  LSI 
yields  dramatic  cost  reductions  and  extraordinary  increases  in  performance.  Because  of 
the  high  design  cost  of  complex  chips,  however,  the  benefits  of  LSI  technology  are  not 


221 


fully  realized  when  used  in  lew  volume  products,  such  as  specialized  or  high- 
performance  computers.  Therefore,  a change  in  computer  architecture  will  take  place 
so  that  the  low  costs  of  LSI  can  be  realized  in  data  processing.  Systems  will  be 
assembled  from  mass-produced  components  — complete  processors  of  various  levels  of 
capability  — configured  around  a main  memory  and  operated  in  both  distributed  and 
parallel  modes. 

In  developing  this  theme,  ADL  postulated  a family  of  component  processors 
likely  to  be  mass-produced  by  a typical  system  vendor.  The  smallest  component 
processor,  level  1,  would  be  comparable  to  today’s  small  minicomputers.  The  level  2 
processor  might  compare  with  an  IBM  System  370/125.  The  large,  level  3,  processors 
would  have  performance  equivalent  to,  say,  a Honeywell  6000  series  CPU. 

Since  a wide  range  of  ADP  capability  was  needed,  four  levels  of  computer 
system  are  described.  The  four  computer  types  (micro-,  mini-,  mono-,  and  multi- 
processor) are  roughly  characterized  in  Table  IV.  Each  would  be  assembled  from 
memory  modules  and  component  processors.  Figure  3 illustrates  how  these  com- 
ponents would  be  organized  in  a multiprocessor  computer,  Redundant,  level  3 
processors  are  used  for  the  main  processing  task  while  redundant,  level  2 components 
are  used  for  file  and  input /output  processing.  Multiprocessors  of  this  type  are  expected 
to  be  organized  primarily  to  provide  ease  of  use.  Sheer  throughput  power  will  be 
sacrificed  to  provide  for  increased  functionality  — multiple,  simultaneous  operating 
system  environments,  for  example. 

The  next  largest  class,  monoprocessors,  will  more  likely  be  configured  for 
maximum  throughput  as  a direct  replacement  for  current  computer  systems.  Their 
capabilities  will  be  similar  to  those  of  current  machines,  but  their  performance  will  be 
faster  (because  of  the  distributed  logic),  and  their  cost  lower.  In  some  respects, 
monoprocessors  are  being  overtaken  in  terms  of  performance  by  small  machines  and 
will  graduate,  with  the  addition  of  further  processors,  to  the  multiprocessor  class. 

The  minicomputer  is  so-called  because  it  will  be  of  comparable  physical  size 
with  current  minicomputers.  In  this  class,  however,  there  is  a rapid  increase  in 
performance  taking  place  through  the  implementation  of  faster  processors,  larger 
memories,  and  more  powerful  operating  systems.  This  class  will  continue  to  be  used  for 
specialized  purposes  (communications  processing,  for  example),  and  to  support  small 
groups  by  executing  a set  of  functional  area  transaction  processes. 
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Figure  3 Multiprocessor  System 


Finally,  the  microcomputer,  similar  to  today’s  microprocessor  but  significantly 
more  powerful,  will  serve  individual  applications,  such  as  pocket  computers,  peripheral 
device  controllers,  and  intelligent  terminals. 

The  trend  to  semiconductor  memory  is  expected  to  continue  strongly  because 
of  steadily  increasing  performance  and  rapidly  decreasing  cost.  By  1980,  these 
memories  may  have  ten  times  the  speed  and  one-tenth  the  cost  of  current  production 
units.  Both  characteristics  will  be  needed  to  meet  the  voracious  demands  of  the  virtual 
operating  systems. 

Auxiliary  Memory 

Few  fundamental  changes  but  a steady  improvement  in  performance  and 
reduction  in  price  are  anticipated  in  auxiliary  storage  technology.  Most  processing 
systems  will  continue  to  use  disk  storage  systems  in  a variety  of  configurations  from 
floppy  disks  to  billion-byte  modules.  Improvement  will  come  in  bit-packing  density 
(leading  to  higher  transfer  rates),  track-packing  density  (reducing  access  times),  and 
head  technology  (leading  to  greater  use  of  head  per  track  disks  and  further  reductions 
in  access  time).  Overall,  a decrease  in  price  per  bit  by  a factor  of  5 to  10  will  be 
available  in  the  next  8 to  10  years. 

In  the  early  1980s,  magnetic  bubble  or  charge-coupled  device  technology  will 
begin  to  be  commercially  available  at  competitive  prices  and  reliabilities.  For  small 
systems  these  devices  will  become  cost  competitive  with  disk  memories;  for  large 
systems,  they  will  provide  a high  speed  buffer  between  disk  and  main  memory. 

Table  V shows  estimated  auxiliary  storage  capacity,  performance  and  price. 

Input/Output  Terminals 

No  dramatic  changes  in  price  or  performance  are  seen  in  the  data  terminal 
market.  Performance  and  reliability  are  usually  limited  by  the  electromechanical 
components  of  these  units,  and  there  aren’t  likely  to  be  any  revolutionary 
improvements  in  this  area.  The  greatest  changes  will  occur  in  the  capabilities  that  can 
be  obtained  at  reasonable  prices  in  “intelligent”  data  terminals  which  will  incorporate 
microcomputer  systems. 

There  will,  however,  be  substantial  advances  in  the  engineering  of  data  handling 
applications.  The  problems  of  data  entry  will  be  increasingly  perceived  as  an  integral 
part  of  the  overall  system  problem.  As  a consequence,  more  care  will  be  taken  in  the 
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Table  V 

Summary  of  Storage  Module  Cost/Performance  Forecasts 


Access  time  25  milliseconds  20  milliseconds 

Cost  $180-220,000  $90-130,000 

Product  example  3333  


selection  of  data  terminals  to  fit  the  need,  in  training  people  to  use  them,  and  in 
providing  the  software  to  help  speed  and  ensure  the  accuracy  of  the  data  entries. 


SOFTWARE 

Software  trends  continue  to  be  far  more  difficult  to  identify  and  project  than 
hardware  trends  because  there  is  as  yet  no  science  of  programming.  However,  a steady 
increase  in  operating  system  capabilities,  and  some  gains  in  programming  productivity 
are  anticipated. 

Operating  System  Software 

Operating  system  software  will  take  advantage  of  distributed  processing  by 
multiple,  special  purpose  processors.  There  will  be  increased  use  of  firmware  and 
hardware  implementations  of  operating  system  functions.  Sophisticated  I/O  controllers 
will  operate  with  less  CPU  supervision  or  intervention  as  they  independently  retrieve, 
index,  and  update  records.  Scheduling  and  dispatching  of  applications  will  be 
implemented  by  hardware  or  by  programmable  read-only  memories. 

For  large  systems,  the  most  striking  development  in  operating  system  design 
will  be  the  greatly  increased  use  of  virtual  memory  and  virtual  machine  organizations. 
Virtual  memory  systems  will  deliver  much  of  the  promised  ease  of  program  design  and 
development,  but  will  cost  more  than  expected  in  terms  of  overhead  time.  These  costs 
can  be  reduced  if  great  care  is  taken  in  performance  measurement  and  evaluation  of 
each  application  as  well  as  of  the  system. 

The  structure  of  virtual  operating  systems  is  likely  to  permit  multilevel  security 
operations  by  1980.  Possibly  this  ability  will  be  achieved  through  implementation  of 
the  security  kernel  techniques  described  in  ESD-MCI-74- 1 . The  increased  use  of 
virtual  memory  and  machine  organizations  makes  widespread  achievement  of  secure 
systems  more  likely. 

Applications  Development  Software 

Familiar  higher  level  languages  like  COBOL,  Fortran  and  PL/1  will  continue  to 
be  used,  but  more  developed  and  reliable  data  base  management  systems  (DBMS) 
designed  for  interactive  use  will  increasingly  replace  the  use  of  ad  hoc  programs.  As  the 
data  management  systems  evolve,  present  distinctions  between  host  language  and 
self-contained  systems  will  disappear.  As  a consequence,  professional  programmers, 

Reproduced  as  Ref.  B—  1 : Computer  Security  Development  Summary / ESD,  AFSC, 
L.G.  Hanscom  Reid,  Bedford,  Mass.,  ESD  MC1~74~1,  30  December  1973. 
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using  host  language  features,  and  functional  area  personnel,  using  transaction  and 
inquiry  features  of  a self-contained  DBMS,  will  be  abie  to  work  cooperatively  sharing 
files  and  processes.  Increased  availability  of  user-oriented  languages  will  broaden  the 
user  base  and  provide  greater  independence  from  software  structures. 

In  addition  DBMS  will  use  improved  backup  and  recovery  techniques  to 
guarantee  data  base  integrity  and  rapid  restoration  after  equipment  or  software  failure. 
Centralized  control  of  access  to  shared  and  unshared  data  bases  will  be  achieved  as  will 
unproved  capabilities  for  checking  data  base  update  transactions. 

Software  Acquisition 

Strategies  for  the  acquisition  of  software  will  be  determined  by  a source 
tradeoff  which  must  evaluate  the  relative  merits  of  prepackaged  software,  contract 
programmers  and  in-house  programmers.  The  real  advantages  of  each  will  be  recognized 
and  exploited. 

Prepackaged  software  is  priced  from  a few  dollars  to  a few  hundred  thousand 
dollars  depending  on  the  complexity  of  the  system.  Typical  prices  for  standard 
application  packages  average  $15,000  to  $20,000  per  installation.  The  market  is 
growing  as  the  number  of  bundled  packages  offered  by  computer  manufacturers 
decreases.  The  Air  Force  will  want  to  give  increasingly  serious  attention  to  the  utility 
and  cost  of  packaged  software,  even  when  some  modifications  are  required  to  meet 
USAF  needs.  Sizable  saving  in  critical  manpower  may  be  possible  with  this  acquisition 
strategy. 

Revisions  of  familiar  applications  and  systems  programs  whose  logical 
procedures  and  structures  derive  from  Air  Force  policies  and  methods  should  probably 
be  developed  by  in-house  personnel. 

Software  Engineering 

Still  an  embryonic  discipline,  software  engineering  is  expected  to  develop 
significantly  over  the  next  several  years.  Several  trends  have  been  noted  that  probably 
will  continue: 

• Greater  automation  will  be  found  in  test  and  evaluation  as  well  as  in  coding. 
Efforts  to  use  automated  requirements  analysis  as  an  aid  to  design  will 
continue,  but  few  applications  are  foreseen  by  the  late  1970s. 
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• Increased  formalization  of  the  software  production  process  will  impose 
firmer  controls  on  programming  language  use  and  on  the  organizational  roles 
of  programmers. 

• More  analytical  proofs  of  programming  correctness  will  be  developed  and 
earlier  validation  of  software  correctness  will  be  achieved. 

• A more  rigorous  approach  to  software  design  and  construction  will  be 
reflected  by  a formalized  succession  of  design  levels  implemented  by  strict 
adherence  to  ground  rules  for  module  definition  and  inter-module  com- 
munications. 


COMMUNICATIONS* 

Technological  developments  in  both  local  and  long  haul  digital  communications 
will  affect  the  implementation  of  SADPR-85.  Digital  switched  networks,  new  methods 
of  sharing  wideband  circuits,  and  low  cost  satellite  circuits  will  all  contribute  to 
significant  reductions  in  communications  costs. 

The  communications  technology  suitable  for  local  use  on  Air  Force  bases  was 
examined  by  the  Base  Communications  Mission  Analysis.  That  study  concluded  that 
coaxial  cable  systems  using  frequency  and/or  time-division  multiplexing  would  provide 
increased  service  and,  given  the  anticipated  demand  for  computer  data  terminals, 
reduced  cost  The  Air  Force  Base  Information  Transfer  System  (AFBITS)  program 
proposes  a prototype  installation  as  soon  as  possible. 

Circuit-Switching  Systems 

The  SADPR-85  study  examined  the  availability  of  leased  circuits  and  the 
expected  costs  of  alternative  sources  (AT&T,  Western  Union,  Southern  Pacific, 
DATRAN,  etc.).  Steady  reductions  in  cost  were  forecast  (50  percent  reduction  by 
1985),  with  some  increase  in  reliability.  Roberts  estimates  that  costs  may  decline  by 
over  60  percent  in  the  same  period.  It  seems  likely  that  this  rate  of  cost  decrease  will 
continue  as  new  switching  and  signaling  technology  is  brought  into  service,  e.g., 
AT&T’s  Digital  Data  Service. 

This  communications  portion  of  the  ADL  forecast  is  provided  for  the  sake 
of  completeness  in  presenting  the  ADL  view.  The  results  and  judgments 
of  this  study  regarding  future  data  communications  are  presented  in 
Section  Vl-A  of  this  report. 

** Reproduced  as  Ref.  B-2:  Data  by  the  Pocket,  L.G.  Roberts,  lEF.t:  Spectrum, 
February  1974. 
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Packet- Switching  Systems* 

The  classic  alternative  to  circuit  switching  has  been  message  switching,  for 
example,  the  store-and-forward  techniques  that  are  used  in  the  AUTODIN  network. 
The  overhead  and  processing  delays  involved  in  the  usual  store-and-forward  systems 
prevent  their  use  for  supporting  remote,  interactive  data  terminals.  The  packet-switch- 
ing concept  is  based  on  an  ability  statistically  to  share  high  speed  circuits  between 
many  users  so  that  each  message  is  transmitted  quickly  while  line  utilization  is 
reasonably  high.  Minicomputers  are  used  to  divide  the  messages  into  short  packets  and 
to  control  the  routing  and  multiplexing  of  packets  along  the  network’s  links.  At  the 
same  time,  the  computers  provide  powerful  error  detection  and  correction  logic,  and 
alternate  routing  schemes  to  increase  reliability.  Processing  costs  are  falling  so  rapidly 
that  they  will  become  a negligible  part  of  network  costs.  Hence,  the  increased  service 
and  performance  of  packet-switching  networks  will  help  them  dominate  the  market  in 
meeting  computer  communications  requirements. 

The  first  large  scale  use  of  packet-switching  technology  was  in  the  ARPANET 
which  now  connects  more  than  50  data  processors  all  over  the  country.  Subsequently, 
commercial  networks  have  been  proposed  (Packet  Communications,  Inc.  and  Telenet 
Corp.)  and  the  proposed  successor  to  AUTODIN  (AUTODIN-II  or  the  Integrated  Data 
Network)  will  be  a packet-switching  network. 

The  economics  of  the  commercial  networks  appear  attractive  for  relatively 
small  users,  but  the  workloads  associated  with  Air  Force  bases  suggest  that  private 
networks  may  be  more  appropriate. 

Satellite  Communications 

The  potential  economies  of  satellite  circuits  are  only  beginning  to  be  felt  Long 
distance  circuits  provided  by  satellite  are  significantly  less  expensive  than  land  lines  or 
ocean  cables  — perhaps  an  order  of  magnitude  less  expensive  by  1980.  By  that  time  a 
combination  of  long  distance  satellite  circuits,  short  distance  land  lines  (less  than  50 
miles,  say),  and  packet-switching  technology  could  reduce  overall  communications 
system  costs  for  some  users  by  a factor  of  five  or  six  relative  to  today’s  costs.  More 
thorough  analysis  of  the  requirements  of  each  specific  application  must  be  made  before 
accurate  cost  estimates  are  feasible. 

*The  definitive  judgments  expressed  here  with  regard  to  network  costs 
relative  to  processing  costs  and  the  relative  role  of  packet  switching 
are  those  of  ADL  and  do  not  reflect  the  views  of  this  study. 
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SYSTEMS 


For  most  data  processing  systems  the  costs  of  ADPE  and  communications  are 
descending  so  much  faster  than  the  costs  of  software  development  that  the  latter  will 
constitute  a large  majority  of  system  costs.  This  is  progressively  less  true,  the  more 
installations  that  a system  requires.  For  a system  involving  over  100  installations, 
equipment  costs  will  continue  to  be  larger  than  software  development  costs  for  some 
time.  Manpower  costs,  however,  are  rising  while  ADPE  costs  decline  so  that  operations 
and  maintenance  costs  are  becoming  a progressively  larger  fraction  of  total  program 
costs.  These  trends  point  toward  increased  use  of  resource-sharing  system  architectures. 
The  benefits  of  these  systems  include  the  following. 

• It  remains  less  expensive  to  acquire  a few  large  computer  systems  than  many 
small  separate  systems  delivering  equivalent  capability. 

• Operations  and  maintenance  expense  for  a few  large  systems  is  less  than  for 
many  medium-to-large  ones. 

• Specialized  equipment  and  capability  can  be  amortized  over  a large 
community  of  users. 

• Workloads  may  be  shared  between  different  processing  elements  of  the 
system  which  thus  readily  adjusts  to  changing  requirements. 

• Backup  can  be  provided  for  failed  components  and  processing  centers. 

• Cooperation,  coordination,  and  mutual  assistance  among  widely  dispersed 
members  of  an  organization  can  be  enhanced. 

• Duplicative  data  base  storage  can  be  reduced,  not  to  minimize  hardware  cost 
as  much  as  to  ensure  that  all  users  are  operating  on  the  basis  of  a common, 
accurate  understanding. 

The  experience  of  Boeing  Computer  Services  illustrates  that  it  is  both 
technically  feasible  and  economically  beneficial  to  use  a resource-sharing  computer 
network  to  meet  widespread  and  similar  data  processing  needs.  Careful  planning  and 
accurate  and  continuing  system  performance  measurements  are  essential  if  the  system 
is  to  perform  well  and  satisfy  its  users  who  have  been  accustomed  to  controlling 
directly  their  ADPE  resource. 


